Wiki源代码第3章评估和计划

由 superadmin 于 2024/04/03, 17:29 最后修改

version	line-number	content
10.1	1
	2
	3
	4	[[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC4%E7%AB%A0%20%E6%B5%8B%E9%87%8F%E5%92%8C%E6%8A%A5%E5%91%8A/]] [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC2%E7%AB%A0%20%E6%88%98%E7%95%A5%E4%B8%8E%E6%8C%87%E5%AF%BC/]]
	5
17.1	6	{{box cssClass="floatinginfobox" title="
	7
	8	Contents"}}
9.1	9	{{toc/}}
	10	{{/box}}
10.1	11
17.1	12	= 第3章评估和计划 =
5.2	13
17.1	14
5.2	15	当规划改进或其他倡议时，了解当前状态至关重要。这使组织能够：
	16
	17	● 比较当前状态与期望的未来状态；
	18
	19	● 找出两个状态之间的差距；
	20
	21	● 开发符合逻辑的计划以弥补这些差距。
	22
	23
17.1	24
5.2	25	== 3.1 评估的基础 ==
	26
17.1	27
5.2	28	评估用于测量、分析和理解行为和性能或绩效。他们应该通过准确反映当前状态来理解改进。在服务管理的背景中，评估通常以SVS的元素为目标，例如服务、实践或价值流。在评估期间，应考虑服务管理四维模型。
	29
	30	存在许多类型的评估，不仅是是作为正式计划的一部分，而且还包括在日常管理活动中。例如，服务供应商组织可能希望整体上改进其提供服务的性能或绩效，这个改进依赖于对每项服务绩效的持续监控和管理。诸如服务台性能或绩效、技术或服务的可用性、重大事件审查以及与变更相关的事件之类的定期报告都是评估的典范。这些可以并且应该用来了解当前状态和计划的改进。
	31
	32	可以在组织的任何级别上进行评估。人们在评估他们的控制范围中的区域时通常会发现他们有权改进的事情。这些复杂的改进对组织朝着理想未来状态的发展产生了真正的影响。
	33
	34
	35
	36	=== 3.1.1 有效评估 ===
	37
17.1	38
5.2	39	目标评估包括进行测量、将其处理为指标度量、将其与期望值进行比较。然后，所有信息都应记录在报告中，该文件应支持评估的发现和做出的决定。应保留以此方式创建的报告，并将其用作与将来评估的比较点。
	40
	41	全面的评估不仅可以确定差距和关注的领域，还可以突出表现良好的生产领域以及可以进一步发展的领域。找出不良做法并要求变更可以促进改进，但是突出积极之处和鼓励良好做法往往更为有效。
	42
	43
17.1	44
5.2	45	==== 3.1.1.1 评估类型 ====
	46
17.1	47
5.2	48	在选择评估方法和技术时，重要的是要了解每个人将产生结果的性质。可以采用一种以上的评估方法，即从不同的角度看待SVS的不同方面，或者看相同的方面。表3.1列出了三种主要的评估类型。
	49
	50	表3.1 评估类型
	51
16.1	52	(% style="width:437px" %)
	53	\|(% style="width:66px" %)定性\|(% style="width:368px" %)利用评估者的知识和体验，定性评估是基于意见的，因此需要进行解释。自我评估主要是定性。
	54	\|(% style="width:66px" %)定量\|(% style="width:368px" %)定量评估以证据为导向，因此更多。这些评估依赖于准确、完整的数据。正式审核通常是定量。
	55	\|(% style="width:66px" %)混合法\|(% style="width:368px" %)定性和定量，混合法评估相结合，涉及专家分析证据并提出意见的过程。当采用混合法方法时，用于识别和实施改进的评估通常最有效。
5.2	56
17.1	57	(% class="wikigeneratedid" %)
	58	==== ====
	59
	60	(% class="wikigeneratedid" %)
	61	==== ====
	62
5.2	63	==== 3.1.1.2 评估目标 ====
	64
17.1	65
5.2	66	评估可以设计为一次性使用，也可以作为常规方案的一部分，以跟踪组织功能的发展。它们应该在改进倡议开始之前、整个过程以及结论中发生。在开始之前，了解评估的目标很重要。评估目标的一些示例是：
	67
	68	● 了解某件事的表现如何；
	69
	70	● 建立基准以测量未来改进活动的结果；
	71
	72	● 了解改进计划是否已实现其目标；
	73
	74	● 将组织的性能或绩效与竞争对手的组织进行比较；
	75
	76	● 了解需求到变更符合标准。
	77
	78	评估目标应该被定义并记录下来。利益相关者了解评估的目标和结果也很重要。如果没有这种共识，将很难制造出符合组织的需求的评估。
	79
	80
17.1	81
	82
5.2	83	=== 3.1.2 收集当前状态数据或其他证据 ===
	84
17.1	85
5.2	86	评估依赖于数据或其他证据。原始数据一旦收集，就应处理成指标度量。指标度量的价值取决于数据的准确性和完整性。其他证据（例如从调查中收集的证据）依赖良好的沟通来传达预期的含义，因此需要进行解释。表3.2概述了五种常见的证据收集方法。
	87
	88	表3.2取证方法
	89
	90	\|收集方式\|输出
	91	\|指标度量/数据挖掘\|来自现有标准报告或挖掘现有数据来源的指标度量
	92	\|调查\|从一系列书面问题得来的反馈
	93	\|访谈\|从一系列口头问题得来的反馈
	94	\|圆桌会议\|互动小组会议收集的反馈
	95	\|观察\|从直接检查以及行为和性能或绩效的测量得出的报告
	96
17.1	97	(% class="wikigeneratedid" %)
	98	==== ====
	99
	100	(% class="wikigeneratedid" %)
	101	==== ====
	102
5.2	103	==== 3.1.2.1 指标度量/数据挖掘 ====
	104
17.1	105
5.2	106	此方法涉及收集相关指标度量或未处理的数据并将其处理为新指标度量。评估能被有效测量的区域使评估更具目的。但是，必须解释指标度量的含义，这会带来主观性。
	107
	108	仅当所基于的数据相关、准确且完整时，这些指标度量才有价值。无法反映现实数据会得出错误的结论。如果所分析的数据没有反映足够的细节，则可能会怀疑所涉及的准确性和完整性。当测量、指标度量和报告源于可靠的数据时，指标度量分析可以产生可信赖的信息，这些信息可以在改进的整个过程中使用。表3.3概述了指标度量/数据挖掘的优缺点。
	109
	110	表3.3指标度量/数据挖掘的利弊
	111
	112	\|优点\|缺点
	113	\|(((
	114	指标度量一旦建立，就可以测量进度，而无需付出额外的努力。
	115
	116	数据推动的工作有助于管理定位问题并快速做出响应。
	117
	118	使用易于理解的指标度量可以帮助建立学习文化。
	119	)))\|(((
	120	对于更大、更复杂的组织，统一的度量变得越来越困难。
	121
	122	有时，直到原始数据的质量改进后，指标度量才可靠。
	123	)))
	124
17.1	125	(% class="wikigeneratedid" %)
	126	==== ====
	127
	128	(% class="wikigeneratedid" %)
	129	==== ====
	130
5.2	131	==== 3.1.2.2 调查 ====
	132
17.1	133
5.2	134	如果使用得当，调查会非常有效。时间非常重要：事态之后立即进行的调查与事态捕获了几周后再进行调查的结果截然不同。适当的调查时间也各不相同：太短，可能无法收集足够的有意义的信息；时间过长，完成率和回应率就会降低。
	135
	136	有效调查的提示包括：
	137
	138	● 最后询问敏感的风险或更高级的问题。
	139
	140	● 评估如何将调查分布到主要社区。
	141
	142	● 避免提出引导性问题和使用绝对值，例如“始终”和“从不”。
	143
	144	● 在不同的论坛上传达调查的目的和价值。
	145
	146	● 确保在适当的保密性。
	147
	148	● 限制开放式问题的数量。
	149
	150	● 个性化邀请以进行回复。
	151
	152	● 试运行口头提问，以确保其清晰。
	153
	154	● 校对文档。
	155
	156	● 发出提醒。
	157
	158	表3.4概述了调查的利弊。
	159
	160	表3.4调查的利弊
	161
	162	\|优点\|缺点
	163	\|调查不是资源密集的，可以匿名完成，可以快速完成。\|(((
	164	关键利益相关者可能没有回应。
	165
	166	低响应率可能影响有效性。
	167
	168	对于性能或绩效，数字响应可能很困难。书面答复可能过于密集而难以解释。
	169	)))
	170
17.1	171	(% class="wikigeneratedid" %)
	172	==== ====
	173
	174	(% class="wikigeneratedid" %)
	175	==== ====
	176
5.2	177	==== 3.1.2.3 访谈 ====
	178
17.1	179
5.2	180	访谈与调查相似，但访谈的性质使访谈者对于提取信息并与受访者建立关系，获得了更大的自由。
	181
	182	许多有效调查的技巧也适用于访谈。具体的访谈技巧包括：
	183
	184	● 留出时间让受访者考虑问题及其答案。
	185
	186	● 视所需答案而定，有意使用开放式或封闭式的问题。
	187
	188	● 答案中没有包括所需要的细节，需要重新回答问题。
	189
	190	● 在整个访谈中保持平和的语气。
	191
	192	表3.5概述了访谈的利弊。
	193
	194	表3.5访谈的利弊
	195
	196	\|优点\|缺点
	197	\|(((
	198	将关键利益相关者作为目标，并收集他们的反馈。
	199
	200	在双向沟通中，将会建立信任并鼓励信息共享。
	201
	202	访谈的形式可以验证最初的答案。
	203	)))\|(((
	204	访谈属于资源密集型。
	205
	206	受访者对访问者的印象会影响他们的反馈。
	207
	208	将会存在偏差。
	209
	210	单独的访谈通常不能收集足够的数据。
	211	)))
	212
17.1	213	(% class="wikigeneratedid" %)
	214	==== ====
	215
	216	(% class="wikigeneratedid" %)
	217	==== ====
	218
5.2	219	==== 3.1.2.4 圆桌会议 ====
	220
17.1	221
5.2	222	圆桌会议与访谈类似，但是具有更多的自发性交互的机会。他们参加小组会议讨论一个主题。组织者精心计划以及主持人引导会议进程，形成了问题、参与者、位置、议程和期望的输出。
	223
	224	小组讨论的性质意味着，参与者可能会遵循与访谈中不同的思维方式。一个参与者的评论将激发另一个想法，对话将朝着新的方向发展。
	225
	226	举办圆桌会议的技巧包括：
	227
	228	● 确保桌上的每个人都参与。
	229
	230	● 举行多个会议，一些参与者来自相似角色，另一些参与者来自不同角色的人。
	231
	232	● 保持中型的会议规模：理想的是每个会议有八个参与者。
	233
	234	● 记录讨论。
	235
	236	● 选择能提供多种观点的参与者。
	237
	238	● 使用经验丰富的主持人来引导会议，不需要限制对话。
	239
	240	● 使用开放式问题。
	241
	242	表3.6概述了圆桌会议的利弊。
	243
	244	表3.6圆桌会议的利弊
	245
	246	\|优点\|缺点
	247	\|(((
	248	将关键利益相关者作为目标，并收集他们的反馈。
	249
	250	如果时间允许，主持人可以探索除了计划问题以外的领域。
	251
	252	答案可以是清晰的也可以是语境化的，可能会增加其价值。
	253
	254	参与者将彼此激发思想，超出他们自己可能想到的范围。
	255	)))\|(((
	256	圆桌会议需要大量准备和专业知识。
	257
	258	圆桌会议属于资源密集型。
	259
	260	受访者对访问者的印象会影响他们的反馈。
	261
	262	将会存在偏差。
	263	)))
	264
17.1	265	(% class="wikigeneratedid" %)
	266	==== ====
	267
	268	(% class="wikigeneratedid" %)
	269	==== ====
	270
5.2	271	==== 3.1.2.5 观察 ====
	272
17.1	273
5.2	274	从源头进行观察意味着要去观察组织中价值创造活动的地方。
	275
	276	观察者应该提出问题。如果他们对实现价值不了解，可能会有所帮助，因为他们没有先入为主的观念。如果观察者熟悉实现价值，则他们可能会做出无效的假设或无法提出基本问题。
	277
	278	观察者应使用评价工具记录其发现。评估的详细程度取决于其目标。例如，如果要定期观察服务台专业人士接听电话并根据他们的互动进行打分，那么详细的评价工具将使主观性降至最低。当规划观察评估时，重要的是要确保评价工具和观察者的知识与评估的目标相匹配。表3.7概述了观察的利弊。
	279
	280
	281	表3.7观察的利弊
	282
	283	\|优点\|缺点
	284	\|(((
	285	观察提供了比调查或访谈更好的证据。
	286
	287	它通过受试者的真实反应提供了对行为的更好描述。
	288
	289	与模型或预测相比，实际结果指标会更好。
	290	)))\|(((
	291	观察会引入高度的观察者偏见。
	292
	293	如果受试者知道正在观察他们，他们的行为可能与正常情况有所不同。
	294
	295	结果的解释取决于观察者的资格。
	296
	297	观察属于时间消耗型。
	298	)))
	299
17.1	300	(% class="wikigeneratedid" %)
	301	=== ===
	302
	303	(% class="wikigeneratedid" %)
	304	=== ===
	305
	306	(% class="wikigeneratedid" %)
	307	=== ===
	308
5.2	309	=== 3.1.3 选择评估方法 ===
	310
17.1	311
5.2	312	收集有关当前状态的信息后，必须对其进行严格分析以评估其含义并准确理解当前的状态。
	313
	314	选择的评估方法将取决于评估的目标和应当的输出。在评估和流程中进行批判性和客观的思考非常重要，以增加其结论有效的可能性。
	315
	316	本节详细研究评估方法，并探讨每种方法的优缺点。在大多数情况下，恰当的使用多种评估方法以清楚了解当前状态。恰当的对同一评估进行几次迭代是改进过程中的必经之路。表3.8概述了各种评估方法及其输出。
	317
	318	表3.8 评估方法及其输出
	319
	320	\|评估方法\|输出
	321	\|差距分析\|识别实际实践与所选评估准则之间的差异。
	322	\|SWOT分析\|确定优势、劣势、机会和威胁。
	323	\|变更准备评估\|组织过渡新工作方式的能力评估。
	324	\|客户/用户满意度分析\|根据客户或用户的反馈，对其的感受进行分析。
	325	\|SLA绩效分析\|基于服务绩效与服务级别协议（SLA）目标的比较，对服务或服务的质量进行分析。
	326	\|基准测试\|此评估的结果与对其他可比较组织进行的类似评估的结果的比较。
	327	\|成熟度评估\|基于定义框架的过程或者组织成熟度进行评估（例如ITIL 流程成熟度模型）。
	328
	329	组织通常会重新使用评估方法，但重要的是，基于当前情况的探索新的备选方案。
	330
	331
17.1	332	(% class="wikigeneratedid" %)
	333	==== ====
	334
5.2	335	==== 3.1.3.1 差距分析 ====
	336
17.1	337
5.2	338	差距分析用于将当前状态与期望状态进行比较。该分析的输出突出显示了两种状态之间差距的性质和范围，并且为计划提供基础使得组织更加接近实现目标。
	339
	340	《AgileSHIFT™指南》（AXELOS，2018年）将此差距称为“增量”。可以通过考虑以下因素来理解增量：
	341
	342	● 组织当前所在的位置
	343
	344	● 所需要的在哪里
	345
	346	● 竞争对手目前的方向或移动趋势
	347
	348	● 客户希望组织所处位置。
	349
	350	增量不是静态的。随着背景的变化和发展，所需的目标状态将不断变化。随着增量的增加，组织应该继续专注于理解它，并朝着理想状态发展。这意味着差距分析应该是连续的实践，而不是一次性的试验。
	351
	352
	353	表3.9概述了差距分析的优缺点。
	354
	355	\|优点\|缺点
	356	\|(((
	357	它支持根据客户期望记录客户体验。
	358
	359	它为确定优先级提供了基础。
	360
	361	它允许收集生产效率度量。
	362
	363	它记录了意外遗漏、故意删除或需要额外开发的产品或服务功能。
	364
	365	它主动比较了当前活动与合规性要求。
	366	)))\|(((
	367	差距分析不是经济的评价方法。
	368
	369	执行类似或重复功能的区域可能不包括在分析的范围中（例如，执行变更管理的事件响应团队）。
	370
	371	解释结果是主观的。
	372	)))
	373
	374	表3.9差距分析的优缺点
	375
	376
	377	(% style="text-align:center" %)
	378	[[image:1639210147215-379.png]]
	379
	380	图片3.1 SWOT分析
	381
	382
17.1	383	(% class="wikigeneratedid" %)
	384	==== ====
	385
5.2	386	==== 3.1.3.2 SWOT分析 ====
	387
17.1	388
5.2	389	SWOT分析可以识别优势、劣势、机遇和威胁。它是确定组织的内部和外部威胁并显示其与竞争对手有何不同的最古老的方法之一。
	390
	391	优势和劣势是影响组织朝着目标前进的能力的内部因素。威胁和机遇是控制之外的外部因素，但是规划进行更改和改进时必须考虑这些因素。
	392
	393	SWOT分析将优势、劣势、机会和威胁归纳为一个列表。该列表通常以简单的网格形式显示，如图片3.1所示。
	394
	395	SWOT分析提供了用于利用组织优势、最小化劣势影响，利用机会并减轻威胁的信息。与其他评估方法一样，SWOT分析可以在组织、部门或个人层面上实施，并且如果作为面对面的小组活动，则是最有效的。
	396
	397	表3.10概述了SWOT分析的优缺点。
	398
	399	表3.10 SWOT分析优势
	400
	401	\|优点\|缺点
	402	\|(((
	403	可以迅速进行编译和交付。
	404
	405	将重点放在战略、管理和运行层面的目标支持。
	406
	407	允许进行隔离以增强优势和机会，同时独立地解决劣势和威胁。
	408
	409	无论主题是战略、商业论证、产品还是服务，都遵循相同的流程。
	410	)))\|(((
	411	确定并安排合适的参与者可能很困难且很耗时。
	412
	413	SWOT分析通常不对结果列表进行优先排序或加权。
	414
	415	SWOT分析是主观的。
	416	)))
	417
17.1	418	(% class="wikigeneratedid" %)
	419	==== ====
	420
	421	(% class="wikigeneratedid" %)
	422	==== ====
	423
5.2	424	==== 3.1.3.3 变更准备评估 ====
	425
17.1	426
5.2	427	变更准备评估对组织准备过渡到一种新工作方式的评估。有许多影响因素会影响组织、部门或团队成功适应变化的能力。在启动变更举措之前，评估这些因素突出显示了其可能成为阻碍其成功的因素。
	428
	429	一个善于接受这种变更并过渡到新的工作方式的组织，是最有可能实现持续改进的潜力组织。如果每个变更都遇到阻力，变更的驱动力会动摇，并可能最终失败。变更准备评估将提供信息，这将有助于指导可能影响变更举措成功的活动。
	430
	431	\|(((
	432	定义: 变更推动者
	433
	434	一个角色，它有助于开发、应用以及倡导新的工作方式。
	435	)))
	436
	437	变更准备评估可能会考虑影响准备的一系列因素，包括组织条件和资源以及利益相关者的态度。
	438
	439	表3.11概述了变更准备评估优缺点。
	440
	441	表3.11 变更准备评估的利弊
	442
	443	\|优点\|缺点
	444	\|(((
	445	允许变更推动者在充分了解问题所在的情况下，解决变更中的人为因素。
	446
	447	在实施变更之前确定潜在的挑战。
	448
	449	增加成功实施并持续实施变更的可能性。
	450	)))\|(((
	451	变更准备评估考虑了可能会使评估人员不知所措的复杂因素。
	452
	453	预测很难使员工对变更准备评估做出反应。
	454
	455	准备变更模型很多，尚待解释。
	456
	457	确定成功变更的障碍并不意味着组织可以或将解决这些障碍。
	458	)))
	459
17.1	460	(% class="wikigeneratedid" %)
	461	==== ====
	462
	463	(% class="wikigeneratedid" %)
	464	==== ====
	465
5.2	466	==== 3.1.3.4 客户/用户满意度分析 ====
	467
17.1	468
5.2	469	对于大多数改进而言，了解客户和用户的满意度水平是有价值的输入。当计划迭代更改时，重要的是要考虑它们将对客户和用户产生的影响。完变更之后，确定满意度的水平是否已按预期提高就很重要。
	470
	471	根据服务的类型，用户和客户的角色可以由不同的人员或组合完成。在后一种情况下，客户旅程、客户体验和客户满意度可能与用户的不同。因此，他们可能需要对评估和分析使用不同的方法。
	472
	473	表3.12概述了客户/ 用户满意度分析的优缺点。
	474
	475	表3.12 客户/用户满意度分析
	476
	477	\|优点\|缺点
	478	\|(((
	479	提供有关产品或服务价值的见解，以及客户和用户对服务供应商履行其承诺的能力的信念。
	480
	481	监视客户和用户对组织的承诺到服务关系的看法。
	482
	483	允许组织衡量变更随时间的变化情况。
	484	)))\|(((
	485	太多的调查会导致疲劳，并且得分不能反映实际意见。
	486
	487	后续行动可能被视为试图销售更多产品而不是更好地理解；他们可能会被忽略。
	488
	489	请求客户和用户的时间可能会严重影响响应。
	490	)))
	491
17.1	492	(% class="wikigeneratedid" %)
	493	==== ====
	494
	495	(% class="wikigeneratedid" %)
	496	==== ====
	497
5.2	498	==== 3.1.3.5 SLA绩效分析 ====
	499
17.1	500
5.2	501	\|(((
	502	定义：服务级别协议（SLA）
	503
	504	服务供应商和客户之间的文档化协议，标识所需的服务和服务的预期级别。
	505	)))
	506
	507	SLA记录了服务供应商及其客户之间已经协商并达成的特定服务级别指标度量和目标。
	508
	509	SLA通常依赖合理的测量和报告。如果未达到服务级别目标，则需要紧急改进。
	510
	511	与其他基于指标度量的分析一样，仅查看指标度量还不足以知道要采取什么措施。必须对指标度量进行严格分析，以确定性能或绩效的正确途径。
	512
	513	SLA绩效分析是一个很好的例子，评估需要持续进行，缺少评估服务质量就难以保证。但是，与正在进行的评估活动一样，应该更广泛地评估SLA绩效，以识别可能需要解决的系统性问题。
	514
	515	表3.13概述了SLA成就分析的利弊。表3.13 SLA成就分析的利弊
	516
	517	\|优点\|缺点
	518	\|(((
	519	有关SLA绩效的信息会引发有关性能、优先级和服务关系的未来的富有成效的对话。
	520
	521	SLA绩效激励着绩效的表现，因为提供者和消费者都意识到这种共同价值。
	522
	523	用于实现SLA的指标度量是最易理解的指标度量之一，他们是很好的思想来源。
	524	)))\|(((
	525	如果SLA中建立的目标不能反映出服务消费者的需求，那么评估能否实现目标就不会反映出消费者的满意度。
	526
	527	与SLA达成相关问题的根本原因可能很难发现且难以解决。
	528	)))
	529
17.1	530	(% class="wikigeneratedid" %)
	531	==== ====
	532
	533	(% class="wikigeneratedid" %)
	534	==== ====
	535
5.2	536	==== 3.1.3.6 基准测试 ====
	537
17.1	538
5.2	539	基准测试是将组织的产品、服务或实践的性能或绩效与类似的组织的产品、服务或实践进行度量的行为。将一个组织与一个表现更好的组织进行比较，可能会突出能够产生切实改进的变更措施。基准测试应该作为持续改进实践的一部分定期进行，以使组织达到或超过竞争对手的性能。它在组织可以成为其他组织对其进行衡量的标准的前提下，也是激励文化变更的宝贵工具。
	540
	541	尽管基准测试通常是在组织级别完成的，但比较高性能组织的特定领域可能更有价值。例如，一个问题经理可能想了解另一个具有较低重大事件发生率的组织在其问题管理实践中的不同之处。与扮演类似角色的对手交谈可以提供有价值的洞察力，这可能会带来有价值的改进倡议。
	542
	543	在进行基准比较之前，重要的是要确保被比较的组织之间具有真正的可比性。例如，同一行业中的两个组织可能服务于截然不同的市场，这使得基准的比较不那么有意义，也没有什么价值。
	544
	545	表3.14概述了基准测试的优缺点。
	546
	547	表3.14 基准测试的优缺点
	548
	549	\|优点\|缺点
	550	\|(((
	551	重点介绍改进的措施。
	552
	553	提供定量和明确的标准，供组织进行比较。
	554
	555	提供竞争分析或潜在合作伙伴的方法。可以针对多个行业进行检查。
	556	)))\|(((
	557	在没有关联组织之间的传递不会是一直很有效。
	558
	559	缺少有效测量。
	560
	561	可以引入基于收入而非实践的行业偏见。
	562
	563	旨在确定行业领导者，从而导致标准化但不一定理想的行为。
	564	)))
	565
17.1	566	(% class="wikigeneratedid" %)
	567	==== ====
	568
	569	(% class="wikigeneratedid" %)
	570	==== ====
	571
5.2	572	==== 3.1.3.7 成熟度评估 ====
	573
17.1	574
5.2	575	成熟度评估是对能力进行评估（通常是流程或组织），用于与成熟度的框架、模型或等级相比较，用于评估的参考模型通常包括多个级别，每个级别描述特定的实践或整个组织的特性。
	576
	577	成熟度评估结果作为成熟度评级与支持证据的详细描述一起出现。组织必须决定评估的成熟度是否可接受；如果不是，则应寻求改进。
	578
	579	组织应该了解成熟度评估的缺点。仅当组织驱动改进时，才将其与外部参考模型进行比较才有价值。很多时候，组织在追求成熟度级别的目标时并不理解达到该水平的重要性。
	580
	581	表3.15概述了成熟度评估的优缺点。
	582
	583	表3.15 成熟度评估的优缺点
	584
	585	\|优点\|缺点
	586	\|(((
	587	优先排序资源以实现成熟度。提供用于测量改进的基线。
	588
	589	设置特定的成熟度目标，从而使组织可以集中精力进行工作。
	590	)))\|(((
	591	成熟度的不同观点可能会妨碍组织的进步能力。
	592
	593	对于组织或流程而言，实现成熟度的代价很高。
	594
	595	风险是目标在于提高成熟度的水平，而不是改进组织或流程。
	596	)))
	597
17.1	598	(% class="wikigeneratedid" %)
	599	=== ===
	600
	601	(% class="wikigeneratedid" %)
	602	=== ===
	603
	604	(% class="wikigeneratedid" %)
	605	=== ===
	606
5.2	607	=== 3.1.4 定义评估目标和准则 ===
	608
17.1	609
5.2	610	了解任何评估的目标都是至关重要的。如果要使用多种类型的评估方法，则必须明确定义每个评估的角色。如果其目标过于广泛，则评估可能会很昂贵且耗时。但是，狭窄的范围不太可能传递足够的信息。
	611
	612	提出并回答某些问题将有助于定义每个评估的关键元素，并确保它们与改进的高级愿景保持一致。特别是，每个评估目的必须经过同意并明确定义。否则以下问题将无法获得有意义的回答。
	613
	614
	615	关键问题包括：
	616
	617	● 评估的目标是什么？
	618
	619	● 评估需要什么信息？
	620
	621	● 评估报告的受众是谁？
	622
	623	● 能够执行评估需要什么？
	624
	625	● 谁来负责评估？
	626
	627	● 谁有需求参加评估？
	628
	629	● 组织或SVS的哪些区域将在评估的范围中？
	630
	631	● 评估需要什么材料或技术？
	632
	633	● 评估将使用什么准则？
	634
	635	● 评估对成功的定义是什么？
	636
	637	● 必须检查组织或SVS的范围内部件的哪些特定方面？
	638
	639	● 评估预期会有什么输出？
	640
	641	● 评估输出应该采用什么形式？
	642
	643	● 评估输出需要包含哪些指标度量？
	644
	645	● 评估应该回答什么问题？
	646
	647	当将评估用作正在进行的管理工具时，至少应每年重新评估一次此信息，以确保所使用的方法仍然有效。
	648
	649
17.1	650	(% class="wikigeneratedid" %)
	651	=== ===
	652
	653	(% class="wikigeneratedid" %)
	654	=== ===
	655
5.2	656	=== 3.1.5 进行评估并产生输出 ===
	657
17.1	658
5.2	659	评估通常是与第三方执行的，但是变更推动者本身必须定义每个评估的目标和范围。一种常见的方法是使用独立的评估程序，因为它们是组织的新手，因此他们常常注意到变更推动者错过的改进机会。
	660
	661	必须仔细考虑使用第三方进行评估是否合适。不这样做可能会节省资金，但可能不会产生所需的结果。在决定是否使用第三方时，请考虑以下几点：
	662
	663	● 内部是否存在技能、经验和所需的资源？
	664
	665	● 内部资源是否具有足够的独立性从而获得公平的评估？
	666
	667	● 内部资源是否足够可信，以确保其结果将被接受？
	668
	669	● 是否可以使用适当的评估准则？
	670
	671	● 与执行内部评估相比，使用第三方的成本是什么？
	672
	673	● 第三方必须提供外部基准测试数据吗？
	674
	675	进行一次成功的评估所需的技能、精力和资源经常被低估。许多评估要求使用内部可能无法使用的特定工具和数据，因此聘请第三方专家通常更便于执行。
	676
	677	评估的两个最重要的输出是数据以及已收集、处理和显示的信息。如果评估的所有输出都是定性而不是定量，则存在更大的偏见或主观性。对数据及其产生的信息的分析将成为支持评估结论的重要证据。
	678
	679	(% style="text-align:center" %)
	680	[[image:1639210445846-683.png]]
	681
	682
	683
17.1	684	(% class="wikigeneratedid" %)
	685	== ==
	686
	687	(% class="wikigeneratedid" %)
	688	== ==
	689
	690	(% class="wikigeneratedid" %)
	691	== ==
	692
5.2	693	== 3.2 计划的基础 ==
	694
17.1	695
5.2	696	在任何组织或团队中，计划可以更好地理解实现目标所需的资源。计划在不知道需要什么新资源或更改资源的情况下更改工作方式将导致不良后果。
	697
	698	计划必须先于性能或绩效，但不应过高到“分析瘫痪”的地步，在该分析中，计划花了太多时间，并制定了策略，使性能或绩效从未启动。敏捷的工作方式鼓励人们着眼于在完美结果之前创建最小可行产品（MVP），特别是避免这种计划的危害。
	699
	700	计划的执行水平应适合正在进行的工作。项目开始时制定的计划在该计划的整个生命周期内都不会是始终符合目标。应该始终对它们进行重新评估和调整。
	701
	702	在工作流程的计划阶段，重要的是要问：“此计划如何与我们的总体战略保持一致？”无论计划看起来多么小或看起来似乎无关紧要，它都应该有助于实现组织的战略目标。计划如果没有这样运行，则可能不值得。
	703
	704
17.1	705	(% class="wikigeneratedid" %)
	706	=== ===
	707
5.2	708	=== 3.2.1 利用计划中的不同工作方式 ===
	709
17.1	710
5.2	711	计划可以采用多种形式，可以利用多种工作方式。计划可以采用的最为熟悉和结构化的形式是项目计划，它可以涵盖多年的工作，其子项目计划和相互依赖的阶段需要数十个人的参与。但是，计划也可以像个人的待办事项清单一样简单。
	712
	713	项目计划可以包括不同的工作方式，具体取决于计划的类型、计划的目标和限制以及相关人员的经验。本部分将介绍探索的三种著名的工作方式：瀑布法、敏捷法和混合法。尽管这些工作方式最初是为在IT 开发项目中使用而创建的，但它们的关键特性也适用于许多其他内容和范围。
	714
	715	应根据所从事的工作类型选择工作方式。选择正确的方法包括考虑项目的需求，变更推动者对每种工作方式的熟悉程度以及每种工作方式所需的资源。
	716
	717	确定是否对计划使用瀑布式、敏捷式或混合法方法并管理方案的工作取决于几个因素。表3.16概述了在决定哪种方法最适合一项倡议时要考虑的重要因素。
	718
	719	表3.16使用瀑布、敏捷和混合法的注意事项
	720
	721	\|瀑布\|敏捷\|混合法
	722	\|要求很明确，不太可能变更\|要求不确定且受限制的变更\|总体要求明确，但细节不确定
	723	\|客户喜欢设定要求并查看预期结果\|客户喜欢参与项目\|定义主要要求后，客户愿意定期地参与
	724	\|组织的失败风险为高\|影响小的故障或其他组织缺陷低\|组织失败的风险重大，但渐进的步骤可能是不完善
	725	\|质量比速度更重要\|快速变化的市场决定了需求用于快速部署\|从一开始就需要有一个广阔的视野，但是显示出渐进式的进程也是很重要
	726	\|管理期望看到正式的性能或绩效计划、指标度量和其他详细文件资料\|可行的解决方案比计划更重要\|管理希望看到一些正式用于项目的计划，但是很好沟通是最重要的
	727	\|很多方面依赖其他SVS的系统、服务或元素\|项目的主题区域或者独立，或者少有依赖\|有一些依赖关系，但它们是易于理解和管理
	728	\|团队成员是只担任一个角色\|团队成员灵活且能够担任多个角色\|团队成员有专长，但也能够跨角色和在小团体
	729
17.1	730	(% class="wikigeneratedid" %)
	731	==== ====
	732
5.2	733	==== 3.2.1.1 瀑布 ====
	734
17.1	735
5.2	736	使用传统瀑布式方法的计划分为不同的阶段。在每个阶段都完成并且产品处于最终状态之前，项目或计划的输出无法交付。在每个阶段结束时，都会进行一次评审，以评估项目的状态，并确定下一阶段是否可以开始。这些检查点有时被称为项目里程碑。
	737
	738	基于瀑布的工作流旨在项目结束时能够提供近乎完美的解决方案。瀑布式方法有许多优点，在某些特定情况下，它是一种最佳的工作方式。例如，瀑布式开发技术很可能用于系统不完整或有故障会导致严重后果的情况。但是，这种工作方式的主要缺点与技术变更的快速发展有关。用这种方法管理的项目通常需要很长时间才能完成，这意味着该技术可能会在最终使用之前超过最终的输出。
	739
	740	瀑布式工作方式的好处包括：
	741
	742	● 它的结构受到控制，每个阶段都有特定的可交付成果。
	743
	744	● 许多人都熟悉瀑布式项目，因此很容易达成期望。
	745
	746	● 阶段一次完成，没有重叠，允许检查点验证进度。
	747
	748
17.1	749	(% class="wikigeneratedid" %)
	750	==== ====
	751
5.2	752	==== 3.2.1.2 敏捷 ====
	753
17.1	754
5.2	755	敏捷的工作方式将项目组织成小的独立单元，称为迭代或冲刺。每个冲刺通常会持续一到三周，并将重点放在该时间段内可以完成和交付的工作上。敏捷规划专注于确定每个冲刺可以完成什么，构建可重复的流程，并帮助团队了解他们在短期内可以实现多少。
	756
	757	以敏捷的工作方式，团队不会立即尝试计划或交付大型生产。他们用计划交付体积更小、功能更强大的产品，这些产品将用较短的时限范围满足客户的需求。
	758
	759	敏捷的工作方式的好处包括：
	760
	761	● 更大的控制：不断对微小的增量开发进行审查和调整。
	762
	763	● 更好的生产效率：项目在小规模的冲刺中完成，从而可以快速部署产品。
	764
	765	● 更好的质量：敏捷工作方式的迭代性质和反馈循环可以使发现、隔离和解决问题的速度更快。
	766
	767	● 更高的客户满意度：敏捷团队与客户紧密合作，可以提供快速的反馈和更改，以适应他们不断发展的需求。
	768
	769
17.1	770	(% class="wikigeneratedid" %)
	771	==== ====
	772
5.2	773	==== 3.2.1.3 混合法 ====
	774
17.1	775
5.2	776	有几种将瀑布式和敏捷方法混合为一种方法的方法。通用方法使用类似于瀑布项目的整体分阶段结构，将需求收集在单个阶段中，然后是高级设计。但是，开发工作是在冲刺中进行的迭代，使用反馈来验证成功并相应地调整即将到来的冲刺。但是，与真正的敏捷项目不同，最终的输出都是在项目的末尾一次性发布的，而不是在每个冲刺的末尾发布的。
	777
	778	混合法工作方式的好处包括：
	779
	780	● 它平衡了瀑布的结构和控制以及敏捷的速度和灵活性。
	781
	782	● 因为最终的输出直到所有的冲刺完成才发布，所以有时间纠正单个冲刺中的错误。
	783
	784	● 对于习惯瀑布式但想学习如何敏捷工作的团队来说，它可以是一种中间方法。
	785
	786
17.1	787	(% class="wikigeneratedid" %)
	788	=== ===
	789
	790	(% class="wikigeneratedid" %)
	791	=== ===
	792
5.2	793	=== 3.2.2 监控计划的进展 ===
	794
17.1	795
5.2	796	不管使用哪种方法，都要定期测量针对计划需求的进度。必须监视和调整计划，即便是瀑布计划和混合法型计划，以确保不需要外部因素进行更改。例如，计划中面向客户的服务可能需要快速修改，以应对竞争对手利用的新技术。如果无法调整计划，则其输出将在交付之前被淘汰。
	797
	798	敏捷的基本前提是，它可以快速地向变更定向，而不会失去动力。在敏捷项目的生命周期内，监控的外部影响和内部压力至关重要。在交付计划的每个迭代时，相关利益相关者提供的监控反馈将指示所需方向的任何变化。
	799
	800	(% style="text-align:center" %)
15.1	801	[[image:1641446247832-725.png]]
5.2	802
	803	(% style="text-align:center" %)
15.1	804	[[image:1641446267045-397.png]]
5.2	805
	806
	807	\|(((
	808	进一步阅读
	809
	810	//PRINCE2 Agile//® (AXELOS, 2015) 为组织提供了适当的结构和治理模型，使团队能够以敏捷的方式工作。
	811	)))
	812
17.1	813	(% class="wikigeneratedid" %)
	814	== ==
	815
	816	(% class="wikigeneratedid" %)
	817	== ==
	818
	819	(% class="wikigeneratedid" %)
	820	== ==
	821
8.1	822	== 3.3 价值流图简介 ==
	823
17.1	824
8.1	825	价值流图是一种将从需求或机会流动到价值可视化的方法，然后在可视化如何规划中改进流动。该方法起源于精益制造技术，但同样适用于产品和服务的创建和交付，如ITIL®4：创建、交付和支持中所述。提供产品和服务时有许多价值流。可以在价值流图中定义用于快速恢复服务，以约定的可用性级别交付服务或管理服务变更的实现价值流程。对于利益相关者，组织所做的一切都应直接或间接映射到价值。
	826
	827	价值流图用于深入了解组织工作流。它可以帮助识别价值流中的添加价值的活动和不添加价值的活动，同时突出显示优化和自动化的机会。价值流图包括评估（记录了从需求到价值的工作流的当前状态）和规划（规划，将对改进对该工作流进行哪些更改）。然而，价值流图最重要的作用是确定必须实施哪些改进行动才能达到预期的未来状态。
	828
	829	价值流图的结果可在许多情况下使用，包括编写商业论证、定义优化价值流和实践的优先列表以及查找现有实践中的瓶颈。
	830
	831	价值流通常跨越许多合作伙伴，供应商和服务消费者组织。但是，对于价值流图来说，新的组织可能需要简单地开始，重点放在组织本身内的价值流的那些方面。随着时间的推移，它可以扩展其价值流图的范围，从而找到更多的优化机会。
	832
	833
17.1	834	(% class="wikigeneratedid" %)
	835	=== ===
	836
8.1	837	=== 3.3.1 精益 ===
	838
17.1	839
8.1	840	精益和价值流图密切相关。精益的核心思想是最大化客户价值，同时最大程度地减少浪费。简而言之，精益意味着用更少的资源为服务使用者创建更多的价值。
	841
	842	应当充分利用各种类型的资源，尤其是人力资源。任何浪费的东西都应该消除，技术应该被最大程度地利用。人为干预只能在确实有助于价值的地方进行。
	843
	844	精益旨在通过零浪费的完美价值创造流程提供完美的价值。精益思想鼓励管理层关注的不是孤立的技术、资产和部门，而是通过整个价值流优化产品和服务的流动，这些价值流水平地跨技术、资产和部门流向服务消费者。
	845
	846
17.1	847	(% class="wikigeneratedid" %)
	848	=== ===
	849
8.1	850	=== 3.3.2 避免局部优化 ===
	851
17.1	852
8.1	853	在许多组织中，专注于单个流程可以优化小型控制范围中的流程中的步骤，例如针对单个团队或部门，同时忽略更改对整个价值流的影响。局部优化会导致在价值流的更下方创建瓶颈，并使整个性能或绩效变差，而不是变好。
	854
	855	消除整个价值流中的浪费，而不是孤立地消除浪费，创造了需要更少人力、空间、资本和时间的流程，从而以更低的成本和更少的缺陷制造产品和服务。
	856
	857	价值流图是优化整个价值链的出色工具。较大的视图与“通盘思考和工作”的导向原则完美对齐。
	858
	859
17.1	860	(% class="wikigeneratedid" %)
	861	=== ===
	862
8.1	863	=== 3.3.3 价值流图的价值 ===
	864
17.1	865
8.1	866	价值流图很有价值，因为它能够：
	867
	868	● 帮助组织可视化超过生产中的单个流程级别
	869
	870	● 帮助组织识别和消除浪费
	871
	872	● 重点介绍需要讨论和制定有关工作流程的决策的地方
	873
	874	● 结合了精益的概念和技术
	875
	876	● 帮助计划和文档改进。
	877
	878
17.1	879	(% class="wikigeneratedid" %)
	880	=== ===
	881
8.1	882	=== 3.3.4 开发价值流图 ===
	883
17.1	884
8.1	885	\|(((
	886	定义：价值流图
	887
	888	服务价值流的可视化直观表示，其显示了工作、信息和资源的流动。
	889	)))
	890
	891	开发价值流图的步骤1是记录当前的工作方式并形成基线。基线突出显示了不会为服务消费者增加价值的步骤或活动，因此可以视为纯粹的浪费。
	892
	893	重要的是，将价值流与一组关键活动的代表进行映射，并鼓励个人对当前状态进行反思以发现瓶颈和其他障碍。这样可以确保包括所有活动，提供对当前状态的共识，并增加接受提议的更改的可能性。在此阶段手动映射价值流可以进一步协作。
	894
	895	定义价值流的当前状态后，小组应确定可以进行的改进，并映射实现后的未来状态。该实践通常集中在识别浪费和改进流动上。表3.17概述了精益中发现的三种废物（术语Muda，Muri和Mura源自丰田生产的系统，这是更通用的精益方法的主要体现）。
	896
	897	Muda浪费类型可以进一步细分为较窄的浪费类型。这些在表3.18中概述。
	898
	899
	900	表3.17废物种类
	901
	902	\|废物种类\|含义
	903	\|Muda\|浪费、无用、徒劳。正在完成但未添加价值的事情。
	904	\|Muri\|负担过重、过度或不合理。由刚性服务、时限范围、发布窗口以及其他此类时间限制引起。
	905	\|Mura\|可变性、不均匀性、不均匀性、不规则性。工作方式或工作流出现不可接受的变化或阻碍。
	906
	907	表3.18 Muda子类别
	908
	909	\|废物种类\|描述
	910	\|货品的运输\|工作流程生产、信息、材料
	911	\|库存\|在制品，多于战略性标准的产品
10.1	912	\|人员移动 \|不必要的物理移动
8.1	913	\|待期\|停止或降低速度，等待工作到达的时间
	914	\|生产过剩\|生产超出需要的数量或超出需要的数量
	915	\|流程冗余\|多余或不必要的工作
	916	\|缺陷和返工\|重做以纠正错误，检查和报废
	917	\|能力\|未被利用的人员创造力和潜力
	918
	919	计划的改进应在商定的时间范围内实施；许多组织将其限制为三个月。短的时限范围可以快速提高，并有助于保持发展势头。这与“基于反馈迭代推进”的指南原则保持一致。如果改进将花费三个月以上的时间来实施，则团队应尝试将其分为可更快实施的阶段。
	920
	921	团队应考虑消费者的反馈，区分影响的高和低。然后应记录价值流的未来状态并将其传达给相关的利益相关者。
	922
	923	随着计划改进的实施，将来的状态价值流图变为当前的状态价值流图。价值流图是迭代的，应将价值流重新映射为工作方式和其他因素变更。
	924
	925
17.1	926	(% class="wikigeneratedid" %)
	927	==== ====
	928
8.1	929	==== 3.3.4.1 增加价值流图中的细节 ====
	930
17.1	931
8.1	932	通过详细介绍流动的步骤来映射价值流。最初，添加了基本信息，以便需求对其进行研究的任何人都可以理解价值流图。这包括概述价值流的输入和输出。
	933
	934	但是，仅提供高级信息还不够。价值流图需要更加具体，以便进行详细分析。当在映射中定义逻辑和可衡量的步骤时，量化工作流程和识别浪费将变得更加容易。
	935
	936	平衡价值流图的细节和清晰度很重要。细节太少，价值流图将难以用于分析和改进。细节太多，将造成混乱。
	937
	938	随着价值流图的流行，表示价值流各个方面的符号也已经开发出来。符号很有价值：它们可以简化和阐明价值流图。最重要的符号是关于浪费的。使用符号突出显示价值流中的各种废物，使它们更易于查看和处理。
	939
	940	能够区分物理流和信息流很重要，因此使用不同的符号来区分它们。另一个有用的符号称为持续爆发。此符号表示需要进一步调查的区域；在这些区域中，团队知道有些问题，但无法确定确切的问题。图片3.2显示了一些价值流图符号。
	941
	942	(% style="text-align:center" %)
	943	[[image:1639210901738-889.png]]
	944
	945	图片3.2 价值流图符号
	946
	947
17.1	948	(% class="wikigeneratedid" %)
	949	=== ===
	950
8.1	951	=== 3.3.5 价值流图中的典型错误 ===
	952
17.1	953
8.1	954	表3.19概述了与价值流图相关的典型错误。
	955
	956	表3.19 价值流图中的典型错误
	957
	958	\|错误\|建议
	959	\|仅将映射用作设计练习\|通常，价值流图仅用于改进价值流性能或绩效，但是它们也可以用于实现价值组织学习，文化转变和领导开发的潜在好处。
	960	\|映射过于复杂\|(((
	961	价值流地图可能变得过于详细和复杂，以至于人们无法理解和使用。
	962
	963	重要的是应用“ 保持简单实用”的指南原则，不要增加不必要的细节。
	964	)))
	965	\|创建映射但不使用性能或绩效\|如果没有用于未来计划的当前和将来状态价值流图，则几乎没有价值。同样，从未实现的计划也浪费了精力。
	966	\|与不适当的团队或根本没有团队进行映射\|因为价值流图是具有战略意义的改进实现价值，并且将来的状态图通常需要大量的组织变革，所以映射团队必须包括可以授权那些更改的利益相关者。
	967	\|创建没有指标度量的映射\|主动测量价值流的元素（例如吞吐量或实现价值持续时间）可以进行分析，理解和比较。
	968
	969	(% style="text-align:center" %)
	970	[[image:1639210933547-115.png]]
	971
	972
17.1	973	(% class="wikigeneratedid" %)
	974	== ==
	975
	976	(% class="wikigeneratedid" %)
	977	== ==
	978
8.1	979	== 3.4 总结 ==
	980
17.1	981
8.1	982	评估是任何持续改进历程的关键部分：定义评估的目标，适当地设定范围以及了解如何从当前状态过渡到未来状态至关重要。如果您在改进的每个迭代之后都使用另一个评估来验证您的结果，那么当规划计划的下一阶段时，这将有所帮助。
	983
10.1	984
	985	[[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC4%E7%AB%A0%20%E6%B5%8B%E9%87%8F%E5%92%8C%E6%8A%A5%E5%91%8A/]] [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC2%E7%AB%A0%20%E6%88%98%E7%95%A5%E4%B8%8E%E6%8C%87%E5%AF%BC/]]

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司

Wiki源代码第3章 评估和计划

Wiki源代码第3章评估和计划