你好，这里是工行架构，我是任长清。

今天我想给你介绍一个做需求整合的高效方法。在规模化的业务研发过程中，我们都遇到过不同业务线的创新需求存在相同或相似的功能设计的情况。在这种情况下，如果不进行整合直接实施研发，就会引发客户体验不佳、企业级服务不一致或一定程度的重复劳动问题，最终都会导致资源浪费。

而我们常说的需求整合，就是优化、合并或组合来自不同单位或渠道，但内容相同或相近的业务需求的管理过程。但这个过程，由于涉及对多个创新需求的统筹管理，整合分析的难度较大。究其原因，一是受限于个体业务经验、专业能力的差异，对需求整合理解不统一、把握不一致；二是在识别相同或相似需求、设计整合方案时没有可操作的方法和抓手，可能出现遗漏的情况。

所以，为了解决这些问题，也是为了推动跨产品、跨渠道、跨专业业务研发的需求整合水平。我们就需要一套有效的方法开展需求整合工作。这个方法必须能够降低整合分析难度，缩小差异，并且提供有力的抓手。这个方法就是基于业务架构的企业级业务需求整合方法。

“基于业务架构的业务需求整合方法”是什么？

那么，“基于业务架构的业务需求整合方法”到底是什么呢？

简单来说，“基于业务架构的需求整合方法”是通过将业务需求与业务架构资产建立关联，再针对关联的结果从产品整合、信息共享、流程联动、服务一致、渠道协同、内外统筹等维度，来识别需求整合机会点，最终设计出业务需求整合方案。

那这个方法又有什么优势呢？这个方法充分发挥了业务架构资产的优势，一是全局性，业务架构经过抽象高度凝炼，涵盖全领域、全渠道、全产品、全流程，可从全局视角展示企业能力和资源分布；二是唯一性，业务架构资产不重不漏，可以作为参照物与需求映射，协助人员快速、有效识别相似或相同需求。

我们利用业务架构把原本依赖人工经验判断需求整合的工作升级为基于业务架构资产的需求整合，可以减少仅凭人工经验识别需求整合机会时的不全面导致同一业务需求重复开发的可能。因此，将需求对应到具备全局性和唯一性优势的业务架构资产上，可以有效开展需求的全局整合管控，大幅提升需求整合质量效率。

如何使用“基于业务架构的需求整合方法”？

那么，这个方法具体包含哪些内容呢？下面我们来拆解下其中所包含的主要步骤。

基于业务架构的企业级需求整合方法主要围绕产品、流程、信息、体验、渠道和生态六个维度，通过业务需求映射业务架构资产、需求相似性分析以及业务需求整合方案设计这三个步骤，实现需求与业务架构资产的匹配，进而达成需求整合。如下图所示：

我们先来看第一步：业务需求映射业务架构资产。简单来说，就是对业务需求进行业务架构影响性分析，将需求内容映射匹配到业务架构中的流程模型、产品模型和实体模型中的相应资产。

需要说明的是，整合维度与业务架构中不同的资产类型有着一定的关联关系。通常情况下，流程维度、体验维度和生态维度的分析结果主要与流程模型有关；产品维度和渠道维度的分析结果主要与产品模型有关；信息维度的分析结果主要与实体模型有关，在后续开展第二步分析业务需求相似性时，我们可以根据第一步输出的业务架构资产映射结果中不同的资产类型，从其对应的整合维度着手开展分析。

此外，我们在做业务需求映射架构资产时，还需要注意遵循逐层细化的原则，也就是先确定业务需求整体关联的业务领域、基础产品、业务对象等高阶的业务架构资产，再逐步将具体需求内容与活动、任务、产品条件、实体等资产建立关联关系。之所以要遵循这个原则，主要是考虑到业务需求分析得越细致、越具体，映射的业务架构资产粒度就越细，从而需求整合机会点挖掘就越充分。

做好业务需求映射业务架构资产后，我们的第二步就是业务需求相似性分析。这一步的关键是要承接好第一步输出的映射结果，依据不同业务架构资产类型以及资产的粒度，结合整合维度，来决定相应的分析侧重。

接下来，我将展开讲讲几种情况下的分析侧重。

首先，对于映射到业务架构中流程模型相同资产的业务需求，如果关联到的是同一组活动，那么就需要重点分析活动与活动之间的流程的联动设计是否完整，对接是否无断点，是否提供了一体化服务，例如在产品协议签订成功页面设计开始交易功能，便于客户在签订协议后直接开始交易。

同时也需要考虑关联的活动是否覆盖了客户办理、银行业务运营的前中后台的完整业务流程，例如业务准备、产品配置、客户准入、协议签订、业务申请办理、审查审批、存续期管理、业务统计、风险控制等各业务环节的功能流程等。除此之外，我们还需要考虑跨渠道衔接或线上线下联动的流程设计是否顺畅，例如在柜面渠道上签订的产品协议是否支持在手机银行渠道上开始交易。

如果业务需求关联的是同一个活动时，则要结合活动流程图考虑该活动流程新增或调整支持的产品、渠道、客户或合作方的差异性，重点是要关注活动内任务与任务间联动设计是否闭环、任务与外部干系人的交互是否完整，以及内外部服务流程、信息传递是否达成闭环。例如在与合作方共同开办的业务流程中，在第三方服务页面中支持客户一键返回手机银行页面开展下一步操作，无需手工退出重新进入，实现内外部信息闭环，流程顺畅。

如果业务需求关联的是同一个任务时，就要考虑该任务调整或新增操作步骤或业务规则在不同产品、渠道、客户或合作方场景下设计的一致性和差异化处理。

其次，对于映射到业务架构中产品模型相同资产的业务需求，如果映射到已有的基础产品时，则需考虑新增产品与存量产品在支持的客户、渠道、合作方方面的一致性。如果映射到同一产品组件内的产品条件时，这就意味着产品的核心功能可能相似，你就需要考虑是否进行产品功能的整合设计。

再者，对于映射到业务架构中实体模型相同资产的业务需求，如果映射至同一业务实体时，就需要考虑实体创建、更新、读取的规则是否一致，以及实体的属性是否完备。

整套方法的最后一步就是：业务需求整合方案设计。这其中既要满足各需求提出方的业务目标，还要考虑采用组件化配置研发的方式实现，满足后续业务部门灵活配置产品的需求：

• 在产品维度，要确保产品定位、功能服务明确清晰，以及与其他产品无重复和无交叉；
• 信息维度，要确保对同一客户信息在不同产品、渠道、系统间共享使用；
• 体验维度，要确保对同类产品在相关渠道的业务模式、服务流程、操作页面等方面服务一致；
• 流程维度，要确保业务办理及运营的前中后台各环节功能完整，产品服务线上线下一体化流程闭环无断点；
• 渠道维度，要确保产品的渠道部署合理、相关渠道间服务协同通畅；
• 在生态维度，要确保根据合作方客户使用习惯、合作场景差异化要求等因素统筹设计对接方式等要素，满足合作场景客户服务需求。

工行的实践案例

在我们工商银行内部，也广泛地使用“基于业务架构的需求整合方法”来避免重复劳动，节省资源，下面我将选取一个实践案例，给你介绍下应用这个方法的效果。

工商银行的个人信贷产品和信用卡产品分别由两个部门支撑运营，但二者之间的业务数据各自使用，互不共享，这就会导致一些信贷业务审批不通过的个人客户却能成功申请信用卡，从而产生了信用卡恶意透支的风险。

在采用基于业务架构的需求整合方法时，我们对信贷产品和信用卡产品开展业务架构资产映射，均映射至调查客户背景、审批客户授信等任务资产。

我们对于这种情况开展了需求整合方案设计，从业务架构层面将原来信贷产品和信用卡产品的开展客户背景调查、审批客户授信信息等多个环节进行分析匹配，对于二者业务目的相同或近似的流程环节实施企业级整合，减少重复冗余的工作步骤。

同时在信息数据方面，针对统一业务流程设计企业级业务实体，确保相关信息数据的采集、识别、存储、使用、管理规则，须遵循共享复用的统一原则，实现客户授信审批相关数据在不同产品、业务、渠道、场景下支持打通共享及联动更新。

课程小结

讲到这里，本节课也就告一段落了。我来总结下本节课的重点内容。基于业务架构的需求整合方法分为三步：

• 第一步，业务需求映射业务架构资产，对业务需求进行业务架构影响性分析，将需求内容映射匹配到业务架构中的流程模型、产品模型和实体模型中的相应资产；
• 第二步，业务需求相似性分析，承接第一步输出的映射结果，依据不同业务架构资产类型以及资产的粒度，结合整合维度，来决定相应的分析侧重；
• 第三步，业务需求整合方案设计，聚焦分析侧重，基于整合维度，开展需求整合方案设计。

基于业务架构的需求整合充分利用企业级业务架构资产，逐业务领域、逐业务流程从产品整合、信息共享、服务一致、流程联动、渠道协同和内外统筹等维度走查，系统性地深入梳理和挖掘需求整合机会点，避免由于个体业务经验和专业能力差异导致的整合分析难度大的问题，同时为需求整合工作提供有力的抓手。

思考题

请结合你的实际工作想一想，最近你在进行什么产品需求设计，需求整合上遇到了什么难题，使用这套方法发现了什么样的需求整合机会点。

如果有什么问题，欢迎在评论区留言，下一讲我们一起看一看如何编写标准化、结构化的业务需求书。