ITIL 4官方核心著作
复制
导出
打印预览
查看源代码
子项
评论
附件 (4)
历史记录
信息
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | **申明：** | ||
| 2 | |||
| 3 | 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。 | ||
| 4 | |||
| 5 | |||
| 6 | 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为AXELOS 持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守AXELOS 和 TSO所申明的所有版权要求。 | ||
| 7 | |||
| 8 | |||
| 9 | 本文档翻译工作参与人员： | ||
| 10 | |||
| 11 | 翻译：段笑雨 | ||
| 12 | |||
| 13 | 审校：李俊杰 | ||
| 14 | |||
| 15 | |||
| 16 | 总审：长河 | ||
| 17 | |||
| 18 | 审核：姚凯 | ||
| 19 | |||
| 20 | 统筹：常宏 | ||
| 21 | |||
| 22 | |||
| 23 | |||
| 24 | ---- | ||
| 25 | |||
| 26 | = **1 关于本文档** = | ||
| 27 | |||
| 28 | 本文档为业务分析实践提供了实用指南，分为五个主要部分，内容包括： | ||
| 29 | |||
| 30 | ●有关实践的一般信息 | ||
| 31 | |||
| 32 | ●实践的流程和活动以及它们在服务价值链中的作用 | ||
| 33 | |||
| 34 | ●参与该实践的组织和人员 | ||
| 35 | |||
| 36 | ●支持该实践的信息和技术 | ||
| 37 | |||
| 38 | ●与实践的合作伙伴以及供应商有关的注意事项。 | ||
| 39 | |||
| 40 | |||
| 41 | == **1.1 ITIL®4 认证要求** == | ||
| 42 | |||
| 43 | 会选择本文档的部分内容作为以下考试的测验内容： | ||
| 44 | |||
| 45 | ●ITIL专家-驱动利益相关者价值 | ||
| 46 | |||
| 47 | ●ITIL专家-高速IT | ||
| 48 | |||
| 49 | 详细信息请参阅相应的考试大纲文档。 | ||
| 50 | |||
| 51 | |||
| 52 | |||
| 53 | ---- | ||
| 54 | |||
| 55 | = **2 一般信息** = | ||
| 56 | |||
| 57 | |||
| 58 | == **2.1 目的和描述** == | ||
| 59 | |||
| 60 | |||
| 61 | * 关键信息 | ||
| 62 | |||
| 63 | 业务分析实践的目的是分析企业的部分或全部，定义其需求，并推荐解决这些需求和或业务问题的方案。解决方案必须有助于为利益相关者创造价值。业务分析使组织能够以有意义的方式传达需求并阐述变革的理由。该实践支持组织设计和描述与组织的目标一致的、可以创建价值的解决方案。 | ||
| 64 | |||
| 65 | |||
| 66 | 业务分析实践确定并阐明了组织和客户的需求，还确定并论证满足该需求所需的解决方案。该实践还包括评估对人员、技术、产品和服务的需求。然而，此实践所开展的活动在不同组织之间可能会有所不同。该实践可以既包括对服务消费者的业务流程的战术和战略分析，也包括相对较窄的信息系统分析和技术要求定义等任务。 | ||
| 67 | |||
| 68 | 业务分析实践确定解决客户和组织需求的最佳解决方案，确保明智地使用有限的投资资金。运用业务分析技术促使明确的服务需求。 | ||
| 69 | |||
| 70 | 业务分析实践正在不断发展以适应数字化组织所采用的敏捷的工作方式等挑战性要求。数字化程度更高的组织需求：更加关注了解战略的迫切要求、客户和用户体验、使用数据和技术的机会，重新构想业务流程，以及拥抱数字化业务架构。 | ||
| 71 | |||
| 72 | 在小型、自治且跨专业的产品团队中出现了敏捷工作方式，促使组织评估设立专门职能部门开展工作的有效性。传统上，将业务分析实践设立为专门的职能，与企业架构管理、软件开发和管理等相关职能并存。在敏捷背景下，业务分析实践与特定团队或角色的关联较少，越来越多的情况是，由产品或服务负责人这样的多技能从业人员执行业务分析实践。当产品团队执行此实践时，该实践不是由项目驱动，而更像是持续的活动。 | ||
| 73 | |||
| 74 | 随着组织数字化转型的发展，数字化解决方案逐渐集成到业务价值流中。因此，业务分析从技术人员和关注业务的团队之间的解释者演变为一种综合性的业务实践。 | ||
| 75 | |||
| 76 | |||
| 77 | == **2.2术语和概念** == | ||
| 78 | |||
| 79 | |||
| 80 | 业务分析角色在每个组织中的定义可能不同。例如，一个组织范围的业务分析实践主聚焦于组织的各个层级和方面，以优化组织的运营，包括组织的产品和服务。这种模式常常出现在进行数字化转型，或寻找机会改善资源、投资组合和运营模式的组织中。组织范围的业务分析涉及众多内外部利益相关者的需要和需求。 | ||
| 81 | |||
| 82 | 在其他组织中，业务分析实践仅限于产品和服务。该实践致力于持续分析客户和用户的需要和需求。该模式通常出现在与服务消费者建立基本关系或合作关系的外部服务提供商当中。 | ||
| 83 | |||
| 84 | 业务分析可视为解决方案生命周期的独立阶段，也可以在生命周期期间持续执行。选择哪种方式取决于组织采用的解决方案的设计和开发方法，后者在数字化敏捷组织中很常见，前者作为一种传统方法，无法在数字化环境中提供足够的敏捷性。 | ||
| 85 | |||
| 86 | 该实践应该了解利益相关者的需求，阐明利益相关者的需求并达成一致，以及确定最佳解决方案，以处理这些需求并满足需求。通常需要和需求可能与预期解决方案的功用、功效或体验有关。 | ||
| 87 | |||
| 88 | |||
| 89 | **定义** | ||
| 90 | |||
| 91 | **功用** 产品或服务满足特定需求而提供的功能。功用可以概括为“服务的作用”，并且可以用于确定服务是否“符合目的”。要拥有功用，服务必须支持消费者的性能或绩效或消除消费者受到的约束。许多服务都可以同时做到这两点。 | ||
| 92 | |||
| 93 | **功效** 确保生产或服务将满足约定的需求。功效可以概括为“服务的性能”，并且可以用于确定服务是否“适合使用”。功效通常涉及与服务使用者需求一致的服务级别。 | ||
| 94 | |||
| 95 | 服务级别可能基于正式的协议，也可能是市场营销信息或品牌形象。功效通常涉及如服务的可用性、容量、安全级别和连续性等领域。如果满足所有定义和商定的条件，则可以说服务提供了可接受的保证或“功效”。 | ||
| 96 | |||
| 97 | |||
| 98 | 以上定义参照的是产品和服务；但是，这种对需要、需求和特性的分类可用于组织架构、合作伙伴关系、运营模式和实践等其他解决方案。取决于业务分析的范围，组织可能需要与之相适应的系统性定义。 | ||
| 99 | |||
| 100 | 取决于确定的范围以及对实践定位，业务分析可以采用各种分析技术。这些技术可能是通用模型（如SWOT）或特定产品有关的技术（如用户故事）。 | ||
| 101 | |||
| 102 | |||
| 103 | === **2.2.1 SWOT分析** === | ||
| 104 | |||
| 105 | SWOT（优势、劣势、机会和威胁）分析通常集合内外部的评估结果，用于评估是否需要某项服务，以及是否应该在内部提供。 | ||
| 106 | |||
| 107 | SWOT分析涉及一个组织的四个具体方面：内部优势、内部劣势、外部机会和外部威胁。图2.1显示了SWOT分析模型。 | ||
| 108 | |||
| 109 | 完成SWOT分析时，注意以下关键点很重要： | ||
| 110 | |||
| 111 | * 可以发展优势 | ||
| 112 | * 必须管理劣势或将其转化为优势 | ||
| 113 | * 应该确定机会 | ||
| 114 | * 必须管理威胁 | ||
| 115 | |||
| 116 | |||
| 117 | (% style="text-align:center" %) | ||
| 118 | [[image:1641305653437-331.png]] | ||
| 119 | |||
| 120 | |||
| 121 | 图2.1 组织级别的SWOT分析 | ||
| 122 | |||
| 123 | |||
| 124 | === **2.2.2 用户故事** === | ||
| 125 | |||
| 126 | 用户故事映射是表达服务需求的常用方法。一个用户故事呈现了一个功能领域，能够促进团队成员的理解，以便将需求转化为产品和服务。用户故事描述了生产或服务的片段。 | ||
| 127 | |||
| 128 | 分析人员可能会收集与客户需求有关的数据，并在用户故事中传达这种需求。用户故事具有非常具体和简单的形式。用户可能需要某些东西才能实现一定的收益。 | ||
| 129 | |||
| 130 | INVEST首字母缩略词提供了一个有用的提示，即用户故事应为： | ||
| 131 | |||
| 132 | * 独立的（Independent） | ||
| 133 | * 可协商的（Negotiable） | ||
| 134 | * 有价值的（Valuable） | ||
| 135 | * 可估算的（Estimable） | ||
| 136 | * 微小的（Small） | ||
| 137 | * 可测试的（Testable） | ||
| 138 | |||
| 139 | //请参见ITIL®4：驱动利益相关者价值的5.2.5节，获取关于用户故事映射的更多信息。// | ||
| 140 | |||
| 141 | |||
| 142 | SWOT分析和用户故事映射只是适用于不同分析范围的不同业务分析技术的示例，还有许多其他技术可用于各种场景。 | ||
| 143 | |||
| 144 | |||
| 145 | == **2.3 范围** == | ||
| 146 | |||
| 147 | 业务分析实践的范围包括： | ||
| 148 | |||
| 149 | * 分析处于不断变化的内外部背景中的组织、架构、业务流程、产品和服务 | ||
| 150 | * 识别并记录利益相关者的需要和需求 | ||
| 151 | * 评估备选方案，推荐解决利益相关者的需求和/或要求的可采取的措施 | ||
| 152 | * 与相关人员和团队交流所推荐的解决方案 | ||
| 153 | |||
| 154 | 有一些活动和责任范围尽管与该实践密切相关，但并不包含在这一实践中。表2.1中列出了这些内容，以及何处可以找到参考的实践。一定要记住，ITIL实践只是在价值流背景中使用的工具集，应根据情况将这些工具组合在一起。 | ||
| 155 | |||
| 156 | 表2.1其他实践指南中描述的与业务分析实践相关的活动 | ||
| 157 | |||
| 158 | |**实现价值**|**实践指南** | ||
| 159 | |改进业务和产品架构|架构管理 | ||
| 160 | |论证新解决方案|组合管理 | ||
| 161 | |优化与利益相关者的互动|关系管理 | ||
| 162 | |定义方向目标和约束|战略管理 | ||
| 163 | |根据确定的解决方案设计产品和服务|服务设计 | ||
| 164 | |验证实现的解决方案|服务验证和测试 | ||
| 165 | |风险分析和响应优化|风险管理 | ||
| 166 | |||
| 167 | |||
| 168 | == **2.4 实践成功因素** == | ||
| 169 | |||
| 170 | |||
| 171 | **定义：实践成功因素** | ||
| 172 | |||
| 173 | 实践的复杂功能型组件，是实践实现目的所必需的。 | ||
| 174 | |||
| 175 | |||
| 176 | 实践成功因素（Practice Success Factor，PSF）不仅仅是一项任务或活动，还包括了所有服务管理四维模型的组件。一个实践中的PSF的活动和资源有不同的性质，但二者共同确保实践的有效性。 | ||
| 177 | |||
| 178 | 业务分析实践包含以下PSF： | ||
| 179 | |||
| 180 | * 建立并持续改进整个组织针对业务分析的方法，确保以一致且有效的方式执行业务分析 | ||
| 181 | * 确保组织及其客户当前和未来的需求得到理解和分析，并及时推荐高效和有效的解决方案 | ||
| 182 | |||
| 183 | |||
| 184 | === **2.4.1 建立并持续改进整个组织的业务分析方法，确保以一致且有效的方式执行业务分析** === | ||
| 185 | |||
| 186 | 组织在产品和服务组合上采用一致的业务分析方法很重要。但是，这并不意味着所有业务分析任务都以相同的方式处理。一种方法可能包括在不同背景下遵循了几种模型，如新产品和服务、变化的需求以敏捷方式或传统方式管理产品或整体方法等。 | ||
| 187 | |||
| 188 | 保持对组织内外部环境的了解对于确保业务分析方法满足组织和客户的需求至关重要。 | ||
| 189 | |||
| 190 | 业务分析是一门智力密集的学科，涉及识别和评估投资决策所需的信息，以及实现满足业务目标的解决方案。因此，业务分析人员利用多种模型帮助应对处理信息的智力挑战。这些模型包括概念、数据、决策、组织、流程、范围和说明，用于支持业务分析活动，包括： | ||
| 191 | |||
| 192 | * 从利益相关者处收集的有关目标、需求和约束等信息 | ||
| 193 | * 向利益相关者提供其履行职责所需的信息 | ||
| 194 | * 识别业务需求并转化为明确表达的需求和/或解决方案建议 | ||
| 195 | * 评估实际解决方案的绩效和价值，并推荐进一步改进 | ||
| 196 | |||
| 197 | |||
| 198 | === **2.4.2 确保组织及其客户当前和将来的需求得到理解、分析，并得到及时、高效和有效的解决方案支持** === | ||
| 199 | |||
| 200 | 业务分析是价值流中的一个重要步骤，该步骤将想法转换为解决方案，实现价值创建。接收者必须能够基于业务分析的结果采取行动。这些分析必须准确描述当前状态和拟议的未来状态，并清楚说明实现这些建议的步骤。 | ||
| 201 | |||
| 202 | 业务分析主要为两者提供输入：寻求满足其要求的解决方案的客户，以及设计、开发和提供这些解决方案的服务提供者团队。 | ||
| 203 | |||
| 204 | 利益相关者要求保证其需求得到了理解。利益相关者需要得到指导，包括可选的方案以及与每个选项相关的收益、成本和风险。为确保这一点，业务分析可能包括对建议的解决方案的商业论证。重要的是要验证利益相关者已经理解了该信息，并且利益相关者在建议的解决方案的实施过程中，在任何需要的时间都能够提供支持。 | ||
| 205 | |||
| 206 | 服务提供者团队需要功能性和非功能性需求，并根据建议修订，如可以单独交付的任何组件的相对优先级。服务提供者团队还需要有关使用该解决方案的背景信息。 | ||
| 207 | |||
| 208 | 除了需求之外，了解感性的背景也很重要。情商和服务同理心对于业务分析的成功至关重要，对于终端用户服务尤其如此。 | ||
| 209 | |||
| 210 | |||
| 211 | == **2.5 关键度量** == | ||
| 212 | |||
| 213 | 应该在每个实践所贡献的价值流背景内评估ITIL实践的有效性和绩效。与任何工具的绩效一样，只能在应用背景下评估ITIL实践的绩效。但是，工具的设计和质量可能会有很大差异，这些差异确定了在按照目的使用时，工具的潜力或有效的能力。有关度量、关键绩效指标（Key Performance Indicator, KPI），以及可以帮助解决此问题的其他技术的指南，请参见“度量和报告”实践指南。 | ||
| 214 | |||
| 215 | 业务分析实践的关键指标映射了它的PSF(实践成功因素)，可以用作价值流背景下的KPI，评估实践对这些价值流的有效性和效率的贡献。表2.2中列出了一些关键指标的示例。 | ||
| 216 | |||
| 217 | 表2.2 实践成功因素关键指标示例 | ||
| 218 | |||
| 219 | |**实践成功因素**|**关键指标** | ||
| 220 | |建立并持续改进整个组织的业务分析方法，确保以一致且有效的方式执行业务分析|((( | ||
| 221 | 利益相关者对组织能够理解其需求并通过解决方案应对的能力的满意度 | ||
| 222 | |||
| 223 | 记录下来的推荐或实施的解决方案与组织战略不一致的数量及影响 | ||
| 224 | |||
| 225 | 与业务分析相关的成本和风险 | ||
| 226 | ))) | ||
| 227 | |确保组织及其客户当前和将来的需求得到理解、分析，并得到及时、高效和有效的解决方案的支持|((( | ||
| 228 | 利益相关者对所推荐解决方案的满意度 | ||
| 229 | |||
| 230 | 确定和实施解决方案所实现的价值（包括收益、成本和风险） | ||
| 231 | |||
| 232 | 分析和推荐解决方案的及时性 | ||
| 233 | |||
| 234 | 确定和推荐解决方案的数量/百分比和效果 | ||
| 235 | ))) | ||
| 236 | |||
| 237 | |||
| 238 | 将指标正确汇总到复杂的度量当中，将使数据更易用于正在进行的价值流的管理，并用于业务分析实践的周期性评估和持续改进。没有唯一的最佳解决方案。度量的基础是整体的服务战略和组织的优先级，以及实践贡献的价值流的目标。 | ||
| 239 | |||
| 240 | |||
| 241 | |||
| 242 | ---- | ||
| 243 | |||
| 244 | = **3 价值流和流程** = | ||
| 245 | |||
| 246 | |||
| 247 | == **3.1 价值流的贡献** == | ||
| 248 | |||
| 249 | 像任何其他ITIL管理实践一样，业务分析实践也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。业务分析实践要与其他实践结合，才可以为消费者提供高质量的服务。该实践贡献的主要价值链活动是： | ||
| 250 | |||
| 251 | * 设计和转换 | ||
| 252 | * 交付和支持 | ||
| 253 | * 契动 | ||
| 254 | * 改进 | ||
| 255 | * 获取或构建 | ||
| 256 | * 计划 | ||
| 257 | |||
| 258 | 图3.1中显示了业务分析实践对服务价值链的贡献。 | ||
| 259 | |||
| 260 | (% style="text-align:center" %) | ||
| 261 | [[image:1641305748707-825.png]] | ||
| 262 | |||
| 263 | 图3.1 业务分析实践对价值链活动所作贡献的热力图 | ||
| 264 | |||
| 265 | |||
| 266 | == **3.2 流程** == | ||
| 267 | |||
| 268 | 为了实现该实践的目的，每个实践可能需要包含一个或多个流程和活动。 | ||
| 269 | |||
| 270 | |||
| 271 | **定义：流程** | ||
| 272 | |||
| 273 | 一组相互关联或交互的活动，可将输入转换为输出。流程接收一个或多个确定的输入，并转换为确定的输出。流程定义活动的顺序及依赖性。 | ||
| 274 | |||
| 275 | |||
| 276 | 业务分析活动形成了两个流程： | ||
| 277 | |||
| 278 | * 设计和维护业务分析方法 | ||
| 279 | * 分析业务和确定解决方案 | ||
| 280 | |||
| 281 | |||
| 282 | === **3.2.1 设计和维护业务分析方法** === | ||
| 283 | |||
| 284 | 该流程的重点是为业务分析建立一致且有效的方法，解决组织的当前和预期的需求。 | ||
| 285 | |||
| 286 | 该流程包括表3.1中列出的活动，并将输入转换为输出。 | ||
| 287 | |||
| 288 | 表3.1 设计和维护业务分析方法流程的输入、活动和输出 | ||
| 289 | |||
| 290 | (% style="width:932px" %) | ||
| 291 | |关键输入|活动|(% style="width:343px" %)关键输出 | ||
| 292 | |((( | ||
| 293 | 组织的原则、政策和愿景 | ||
| 294 | |||
| 295 | 组织战略 | ||
| 296 | |||
| 297 | 组织架构 | ||
| 298 | |||
| 299 | 产品和服务组合 | ||
| 300 | |||
| 301 | 客户组合 | ||
| 302 | |||
| 303 | 业务分析记录和评审报告 | ||
| 304 | |||
| 305 | 审计报告 | ||
| 306 | )))|((( | ||
| 307 | 分析组织和需求 | ||
| 308 | |||
| 309 | 开发业务分析方法并达成一致 | ||
| 310 | |||
| 311 | 评审业务分析方法 | ||
| 312 | )))|(% style="width:343px" %)((( | ||
| 313 | 业务分析方法，包括范围、方法和技术、程序和职责 | ||
| 314 | |||
| 315 | 改进倡议和变更请求 | ||
| 316 | ))) | ||
| 317 | |||
| 318 | 图3.2显示了流程的工作流程图 | ||
| 319 | |||
| 320 | |||
| 321 | (% style="text-align:center" %) | ||
| 322 | [[image:1641305800678-583.png]] | ||
| 323 | |||
| 324 | |||
| 325 | 图3.2 设计和维护业务分析方法的工作流 | ||
| 326 | |||
| 327 | |||
| 328 | 表3.2 设计和维护业务分析方法的活动 | ||
| 329 | |||
| 330 | |**活动**|**组织范围的业务分析**|**专注于产品的业务分析** | ||
| 331 | |分析组织和需求|组织的领导者分析组织的战略和组合，并确定业务分析实践的角色和范围，及其在组织中的定位|CIO、产品负责人、架构师和业务分析人员评审有关组织的战略和需求的信息，并确定业务分析实践的角色和范围，及其在组织中的定位 | ||
| 332 | |开发并同意业务分析方法|业务分析师、架构师、产品负责人和组合经理开发，同意并交流组织范围内的业务分析方法，包括范围、方法和技术、程序和责任|业务分析师、产品架构师和产品负责人开发，同意并交流以产品为中心的业务分析方法，包括范围、方法和技术、程序和职责 | ||
| 333 | |评审业务分析方法|基于业务分析记录，定期评审和审计报告，业务分析师与产品负责人、架构师和项目组合经理评审业务分析方法的有效性，为“分析组织和需求”活动提供输入，并/或启动所需的变革|基于业务分析记录和定期评审，业务分析师与产品负责人评审业务分析方法的有效性，为“分析组织和需求” 提供输入，并/或启动所需的变革 | ||
| 334 | |||
| 335 | |||
| 336 | === **3.2.2 业务分析和确定解决方案** === | ||
| 337 | |||
| 338 | 该流程专注于分析利益干系人的需要和需求，包括确定和提出解决方案以解决利益干系人的需要和需求。 | ||
| 339 | |||
| 340 | 表3.3 业务分析和确定解决方案的输入、活动和输出 | ||
| 341 | |||
| 342 | |**关键输入**|**活动**|**关键输出** | ||
| 343 | |((( | ||
| 344 | 业务分析方法 | ||
| 345 | |||
| 346 | 组织战略 | ||
| 347 | |||
| 348 | 利益相关者的需要 | ||
| 349 | |||
| 350 | 利益相关者的需求 | ||
| 351 | |||
| 352 | 组织的产品组合 | ||
| 353 | |||
| 354 | 架构模型和约束 | ||
| 355 | |||
| 356 | 风险日志 | ||
| 357 | |||
| 358 | 相关行业趋势和机会 | ||
| 359 | )))|((( | ||
| 360 | 启发和分析利益相关者的信息 | ||
| 361 | |||
| 362 | 定义解决方案选项并确定推荐的解决方案 | ||
| 363 | |||
| 364 | 为解决方案交付团队提供支持 | ||
| 365 | |||
| 366 | 评估解决方案的绩效和价值 | ||
| 367 | )))|((( | ||
| 368 | 业务分析报告 | ||
| 369 | |||
| 370 | 建议和推荐方案 | ||
| 371 | |||
| 372 | 修订风险日志、知识库和其他信息资源 | ||
| 373 | ))) | ||
| 374 | |||
| 375 | |||
| 376 | 表3.4 业务分析和解决方案标识流程的活动 | ||
| 377 | |||
| 378 | |**活动**|**样例** | ||
| 379 | |启发和分析利益相关者的信息|业务分析人员与主要利益相关方互动，了解他们的需要和需求。这可以采取访谈、观察、文件和记录分析以及研讨会的形式。业务分析人员创建业务分析报告，报告包括跟踪矩阵，以便在整个方案交付和支持过程中验证需求。 | ||
| 380 | |定义解决方案选项并确定推荐的解决方案|((( | ||
| 381 | 业务分析人员与相关的领域管理专家SME一起起草两个或多个候选的解决方案，解决现有的业务需求和差距，并比较分析以证明其中一种选项是合理的。然后，业务分析人员向指定的决策方提供解决方案选项，以及推荐的理由。 | ||
| 382 | |||
| 383 | 业务分析人员将指导决策方（如服务发起人、赞助人或产品负责人）做出决策，并协助启动解决方案交付计划。 | ||
| 384 | ))) | ||
| 385 | |为解决方案交付团队提供支持|((( | ||
| 386 | 业务分析人员可帮助设计人员、开发人员、质量保证和部署以及运营团队理解和实现需求。 | ||
| 387 | |||
| 388 | 业务分析人员还可以参与解决方案交付和运维期间的意识和沟通工作。 | ||
| 389 | ))) | ||
| 390 | |评估解决方案的绩效和价值|((( | ||
| 391 | 业务分析人员评估解决方案的运行情况，并监测解决方案为利益相关者带来的额外价值。业务分析人员比较实现的收益与需求和业务目标，然后在持续改进登记册中提交新的改进措施项目。 | ||
| 392 | |||
| 393 | 业务分析人员在整个交付和支持过程中管理对业务需求的变更。新确定的需要和需求作为“从利益相关者获取和分析信息”活动的输入，还可以作为“ 设计和维护业务分析方法”流程的输入。 | ||
| 394 | ))) | ||
| 395 | |||
| 396 | |||
| 397 | 图3.3显示了业务分析和确定解决方案流程的工作流程。 | ||
| 398 | |||
| 399 | (% style="text-align:center" %) | ||
| 400 | [[image:1641305830356-743.png]] | ||
| 401 | |||
| 402 | 图3.3 业务分析和解决方案标识流程的工作流程 | ||
| 403 | |||
| 404 | |||
| 405 | |||
| 406 | ---- | ||
| 407 | |||
| 408 | = **4 组织和人员** = | ||
| 409 | |||
| 410 | |||
| 411 | == **4.1 角色、能力和责任 ** == | ||
| 412 | |||
| 413 | 实践指南没有描述实践的管理角色，如实践负责人、实践领导或实践教练。相反，实践指南专注于每个实践特有的专业角色。每个角色的结构和命名都可能因组织而异，因此不要认为ITIL中定义的角色是强制性的，这些角色甚至不是推荐性的。请记住，角色不是职务名称。一个人可以承担多个角色，一个角色可以分配给多个人。 | ||
| 414 | |||
| 415 | 在流程和活动的背景下描述角色。表4.1中所示的模型描述了不同角色所具有的能力特征。 | ||
| 416 | |||
| 417 | 表4.1能力代码和资料 | ||
| 418 | |||
| 419 | |**能力代码**|**能力概要（活动和技能）** | ||
| 420 | |L|**领导者**（Leader）:决策，授权，监督其他活动，提供奖励和激励，以及评估结果 | ||
| 421 | |А|**管理员**（Administrator）：分配任务并确定优先级，保留记录，进展报告，以及发起基本的改进 | ||
| 422 | |C|**协调者/沟通者**（Coordinator/communicator）：多方协调，保持利益相关者之间的沟通，开展意识教育活动 | ||
| 423 | |М|**方法和技术专家**（Methods and techniques expert）**：**设计和实施工作技术，编制程序文件，提供流程咨询，工作分析以及持续改进 | ||
| 424 | |Т|**技术专家**（Technical expert）**：**提供技术（IT）专业知识和基于专业知识的任务 | ||
| 425 | |||
| 426 | |||
| 427 | 表4.2 负责业务分析活动的角色示例 | ||
| 428 | |||
| 429 | |**活动**|**负责角色**|**能力简介**|**具体技能** | ||
| 430 | |(% colspan="4" %)业务分析方法的设计和维护 | ||
| 431 | |分析组织及其需求|((( | ||
| 432 | 组织负责人 | ||
| 433 | |||
| 434 | 团队负责人 | ||
| 435 | |||
| 436 | 业务分析师 | ||
| 437 | |||
| 438 | 架构师 | ||
| 439 | |||
| 440 | 产品负责人 | ||
| 441 | |||
| 442 | 产品组合经理 | ||
| 443 | )))|TCA|((( | ||
| 444 | 对组织、环境、产品组合、产品、资源和客户有很好的了解 | ||
| 445 | |||
| 446 | 了解业务分析框架 | ||
| 447 | ))) | ||
| 448 | |开发业务分析方法并达成一致|((( | ||
| 449 | 业务分析师 | ||
| 450 | |||
| 451 | 架构师 | ||
| 452 | |||
| 453 | 产品负责人 | ||
| 454 | )))|TLMC|((( | ||
| 455 | 对组织、环境、产品组合、产品、资源和客户有很好的了解 | ||
| 456 | |||
| 457 | 战略思维 | ||
| 458 | |||
| 459 | 领导技能 | ||
| 460 | ))) | ||
| 461 | |(% colspan="4" %)对业务分析技术及其框架有深入的了解 | ||
| 462 | |评审业务分析方法|((( | ||
| 463 | 业务分析师 | ||
| 464 | |||
| 465 | 架构师 | ||
| 466 | |||
| 467 | 产品负责人 | ||
| 468 | )))|TCA|((( | ||
| 469 | 对组织、环境、产品组合、产品、资源和客户有很好的了解 | ||
| 470 | |||
| 471 | 了解业务分析技术和框架 | ||
| 472 | |||
| 473 | 战略思维 | ||
| 474 | ))) | ||
| 475 | |(% colspan="4" %)业务分析和确定解决方案流程 | ||
| 476 | |启发和分析利益相关者的信息|((( | ||
| 477 | 业务分析师 | ||
| 478 | |||
| 479 | 产品负责人 | ||
| 480 | )))|CT|((( | ||
| 481 | 了解利益干系人的背景 | ||
| 482 | |||
| 483 | 对环境、当前的解决方案和约束有很好的了解 | ||
| 484 | |||
| 485 | 分析技能，业务分析技术和框架的专业知识 | ||
| 486 | ))) | ||
| 487 | |定义候选解决方案并确定推荐的解决方案|((( | ||
| 488 | 业务分析师 | ||
| 489 | |||
| 490 | 产品负责人 | ||
| 491 | |||
| 492 | 解决方案设计师服务负责人 | ||
| 493 | )))|TC|((( | ||
| 494 | 了解利益干系人的背景 | ||
| 495 | |||
| 496 | 对环境、当前的解决方案和约束有很好的认识 | ||
| 497 | |||
| 498 | 了解目标架构和相关约束 | ||
| 499 | |||
| 500 | 对可用技术和相关机会有很好的认识 | ||
| 501 | |||
| 502 | 业务分析技能、业务分析技术和框架方面的专业知识 | ||
| 503 | |||
| 504 | 对组织解决方案设计，开发和运营的具有良好认知 | ||
| 505 | ))) | ||
| 506 | |为解决方案交付团队提供支持|((( | ||
| 507 | 业务分析师 | ||
| 508 | |||
| 509 | 产品负责人 | ||
| 510 | |||
| 511 | 服务负责人 | ||
| 512 | )))|TC|((( | ||
| 513 | 对组织解决方案的设计，开发和运营的方法有很好的认知 | ||
| 514 | |||
| 515 | 沟通技巧 | ||
| 516 | ))) | ||
| 517 | |评估解决方案的性能或绩效和价值|((( | ||
| 518 | 业务分析师 | ||
| 519 | |||
| 520 | 产品负责人 | ||
| 521 | )))|T|了解利益干系人的背景 | ||
| 522 | |(% colspan="3" %)服务负责人|((( | ||
| 523 | 对环境、当前的解决方案和约束有很好的了解 | ||
| 524 | |||
| 525 | 分析技能、业务分析技术和框架的专业知识 | ||
| 526 | ))) | ||
| 527 | |||
| 528 | |||
| 529 | === **4.1.1 业务分析师** === | ||
| 530 | |||
| 531 | 本实践中的关键角色是业务分析师，根据实践范围，业务分析师可以专长于组织层面或以解决方案为重点的基础层面。该角色可以由专门的团队执行，也可以归属于产品负责人；后者通常出现在以解决方案为中心的业务分析中。 | ||
| 532 | |||
| 533 | 业务分析人员角色与调查人员相似，需要面对未知的事物、收集证据、询问证人并得出一个他们可以随后验证的假设。该角色可能不需要特定的技术技能和知识，但是需要敏捷性、系统性思考和创造力。 | ||
| 534 | |||
| 535 | 组织通常会聘请经验丰富的业务分析人员探索新解决方案空间，或者是在业务领域中，或是伴随解决方案技术，或两者兼而有之。第一步是掌握和阐明利益干系人需求要解决的问题，并收集可能的解决方案。精通业务分析的角色有一些人格特质，例如： | ||
| 536 | |||
| 537 | * 坚持不懈和分析思维 | ||
| 538 | * 对各种问题解决方法具有强大的把控能力 | ||
| 539 | * 快速掌握新模型并在其中找到最重要的对象和关系的能力 | ||
| 540 | * 对新思想持开放态度 | ||
| 541 | |||
| 542 | 业务分析师在以技术术语传达业务要求方面扮演着至关重要的角色。在解决方案的生命周期中，无论使用何种开发和交付方法，业务分析员都应该是与需求相关信息请求的主要知识来源。 | ||
| 543 | |||
| 544 | |||
| 545 | |||
| 546 | ---- | ||
| 547 | |||
| 548 | = **5 信息和技术** = | ||
| 549 | |||
| 550 | |||
| 551 | == **5.1 信息交流** == | ||
| 552 | |||
| 553 | 业务分析实践的效果取决于所使用信息的质量。这些信息包括但不限于以下信息： | ||
| 554 | |||
| 555 | * 组织的战略 | ||
| 556 | * 组织的环境和主要利益相关者 | ||
| 557 | * 组织的产品组合：资源、产品和服务以及客户 | ||
| 558 | * 组织的架构路线图 | ||
| 559 | * 组织的服务使用者的战略、架构和运营模式 | ||
| 560 | * 服务配置和IT资产信息 | ||
| 561 | * 变更排程 | ||
| 562 | * 持续改进登记册 | ||
| 563 | * 组织架构 | ||
| 564 | * 技术趋势 | ||
| 565 | |||
| 566 | 这些信息可以采用各种形式。业务分析实践的关键输入和输出在第3节中列出。 | ||
| 567 | |||
| 568 | |||
| 569 | == **5.2 自动化和工具** == | ||
| 570 | |||
| 571 | 业务分析实践的自动化集中在增强信息交换的三个主要方面： | ||
| 572 | |||
| 573 | * 办公自动化工具：文档、电子表格和演示工具 | ||
| 574 | * 分析和建模工具，如计算机辅助设计、图表和数据建模工具 | ||
| 575 | * 通信工具，如工作流、任务管理和通信系统 | ||
| 576 | |||
| 577 | 表5.1列出了业务分析实践的每个实现价值相关的具体自动化方法。 | ||
| 578 | |||
| 579 | |||
| 580 | 表5.1 业务分析的自动化解决方案活动 | ||
| 581 | |||
| 582 | |**活动**|**自动化方法**|**关键功能**|((( | ||
| 583 | **对实践有效性** | ||
| 584 | |||
| 585 | **的影响** | ||
| 586 | |||
| 587 | |||
| 588 | ))) | ||
| 589 | |(% colspan="4" %)业务分析方法的设计和维护 | ||
| 590 | |分析组织和需求|((( | ||
| 591 | 通讯和协作工具 | ||
| 592 | |||
| 593 | 分析系统知识 | ||
| 594 | |||
| 595 | 知识管理工具 | ||
| 596 | )))|从各种来源收集、处理和演示数据|高 | ||
| 597 | |开发并同意业务分析方法|通讯和协作工具|协作和信息共享|中 | ||
| 598 | |评审业务分析方法|((( | ||
| 599 | 通讯和协作工具 | ||
| 600 | |||
| 601 | 分析系统知识 | ||
| 602 | |||
| 603 | 知识管理工具 | ||
| 604 | )))|((( | ||
| 605 | 从各种来源收集，处理和演示数据 | ||
| 606 | |||
| 607 | 仪表盘系统的报告引擎 | ||
| 608 | )))|高 | ||
| 609 | |(% colspan="4" %)业务分析和解决方案 | ||
| 610 | |启发和分析利益相关者的信息|((( | ||
| 611 | 协作和通讯工具集 | ||
| 612 | |||
| 613 | 分析系统 | ||
| 614 | |||
| 615 | 知识管理工具 | ||
| 616 | )))|((( | ||
| 617 | 与利益相关者的全渠道沟通 | ||
| 618 | |||
| 619 | 从各种来源收集、处理和演示数据 | ||
| 620 | )))|高 | ||
| 621 | |定义解决方案选项并确定推荐的解决方案|((( | ||
| 622 | Office 生产效率工具 | ||
| 623 | |||
| 624 | 协作和通讯工具集 | ||
| 625 | |||
| 626 | 解决方案设计和 | ||
| 627 | |||
| 628 | 开发系统 | ||
| 629 | )))|演示文稿、电子表格和文档管理|高 | ||
| 630 | |为解决方案交付团队提供支持|((( | ||
| 631 | 工作流程和任务管理工具 | ||
| 632 | |||
| 633 | 协作和通讯工具 | ||
| 634 | |||
| 635 | 办公室生产效率 | ||
| 636 | |||
| 637 | 工具 | ||
| 638 | )))|工作规划和跟踪演示管理|中 | ||
| 639 | |评估解决方案的绩效和价值|((( | ||
| 640 | 协作和通讯工具集 | ||
| 641 | |||
| 642 | 知识管理工具 | ||
| 643 | |||
| 644 | 报告系统 | ||
| 645 | )))|((( | ||
| 646 | 与利益相关者的全渠道沟通 | ||
| 647 | |||
| 648 | 从各种来源收集、处理和演示数据 | ||
| 649 | )))|中 | ||
| 650 | |||
| 651 | |||
| 652 | |||
| 653 | ---- | ||
| 654 | |||
| 655 | = **6 合作伙伴和供应商** = | ||
| 656 | |||
| 657 | 内部和商业服务提供者从外部获取业务分析实践的情况并不少见。外部资源可以拥有更大的可用性，并有动力在商定的有限时限范围内提供解决方案。 | ||
| 658 | |||
| 659 | 产品开发团队的外包经常呈现“内在”的业务分析能力，其中业务分析职能与参与解决方案交付的其他角色紧密合作，从而实现了更高效的信息交换。 | ||
| 660 | |||
| 661 | 但是，内部业务分析自有其优点，主要是因为它对业务领域具有持续的了解。内部业务分析人员更积极与利益相关者所面临的挑战产生共鸣。由于他们是内部员工，因此也比外部业务分析师更有激情。 | ||
| 662 | |||
| 663 | 在进行数字化转型的组织中，业务分析更有可能用于更广泛的范围，可以更好地了解组织的背景。这使业务分析成为推动组织战略发展和领导力的关键实践，因此，业务分析更有可能被保留而不是外包。 | ||
| 664 | |||
| 665 | 无论实践在组织中的定位如何，对组织的依赖关系和伙伴关系的良好理解对于业务分析的有效性都是至关重要的。 | ||
| 666 | |||
| 667 | |||
| 668 | |||
| 669 | |||
| 670 | ---- | ||
| 671 | |||
| 672 | = **7 重要提示** = | ||
| 673 | |||
| 674 | 实践指南的大部分内容都应视作给组织在某些领域的建议，这些领域是组织在建立和培养自己实践时可能需要考虑的。实践指南是组织可能考虑的事项目录，而不是答案清单。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则： | ||
| 675 | |||
| 676 | * 聚焦价值 | ||
| 677 | * 从你所处的地方开始 | ||
| 678 | * 基于反馈迭代推进 | ||
| 679 | * 协作和提升可视化程度 | ||
| 680 | * 通盘思考和工作 | ||
| 681 | * 保持简单实用 | ||
| 682 | * 优化和自动化 | ||
| 683 | |||
| 684 | 有关指导原则及其应用程序的更多信息，请参见ITIL®基础：ITIL 4版出版物的第4.3节。 | ||
| 685 | |||
| 686 | |||
| 687 | |||
| 688 | |||
| 689 | ---- | ||
| 690 | |||
| 691 | = **8 致谢** = | ||
| 692 | |||
| 693 | AXELOS 有限公司非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。 | ||
| 694 | |||
| 695 | |||
| 696 | == **8.1 作者** == | ||
| 697 | |||
| 698 | Konstantin Naryzhny, Mark Smalley | ||
| 699 | |||
| 700 | |||
| 701 | == **8.2 审稿人** == | ||
| 702 | |||
| 703 | |||
| 704 | Monika Perendyk，Bas van Gils，Dinara Adyrbayeva，Roman Jouravlev |