金融公司业务分析框架创建

业务需求是IT项目和其他许多IT工作的起点，它也是业务分析领域的核心。业务需求的质量支配着IT解决方案所需的时间和花费。目前关于业务分析或需求的文章主要从单个角色，即业务分析师的角度来阐述如何收集和分析业务需求。以金融企业为背景，同时从企业和个人的角度系统地阐述如何制订、实施、执行和测量业务分析和需求流程的论述几乎没有。笔者将就此话题与读者进行探讨。

一、业务分析的目的与常见问题

本文所讨论的需求和业务分析主要针对金融行业，如银行、保险公司和贷款机构等。业务分析的目的：确保IT或非IT的解决方案符合业务拥有者或客户的期望；识别并清楚定义真正的业务问题和业务机会；确保IT部门为业务部门或客户做正确的事并且交付正确的结果；确保业务部门或客户得到他们真正需要的；将项目成本的收益最大化。目前企业中业务分析领域常见的问题：低质量的需求，例如需求不清楚、不完整、描述模糊、界限和范围定义不清楚等；现有的流程或模板存在各种各样的漏洞，例如业务分析的某些方面并没有覆盖到；对现有的流程和系统缺乏了解；企业有自己的业务分析和需求流程，但并没有相关的指南和模板，每个项目所采用的文档格式和原则不一样；业务分析师缺乏适当的业务分析技能，例如不知道如何采用用例分析模式(UseCaseModeling),即项目的需求分析流程自始至终由用例驱动；没有统一的需求变更的批准、记录和跟踪方式。

二、高质量需求和业务分析的要素

大型金融企业有大量不同规模、复杂程度及特性的IT项目和维护工作，业务分析师的业务水平参差不齐。大型企业要达到高质量的需求和业务分析，仅寄希望于业务分析师的努力是远远不够的，需要从四方面，即人、流程、治理和测量来构建和实施高质量的业务流程和框架。业务分析师：人的要素即业务分析师，在北美类似的职位还有业务系统分析师、业务专家、业务顾问等。它是作为商业和IT之间的桥梁，介于客户和IT团队之间，在IT项目中负责发掘、分析、传达和确认客户的需求。同时了解有关业务的各种问题并发现新的业务机会，给出解决方案；参与系统的设计、测试和实施以及各种协调工作。根据笔者和其他同行的经验，北美的需求分析师和软件开发人员的最佳比例应介于1：2和1：4之间，有的公司或项目可以达到1：5或1：6，但当比例达到或超过1：7或1：8时，需求分析师的工作量和压力明显加大，工作质量明显下降。流程：除了确保业务分析师能够交付高质量的工作外，还需要识别和制订相应的流程和规则。业务分析不仅包含需求开发流程，还有需求管理和风险管理流程。只有流程是不够的，还需要明确适用于业务分析的组织级基本原则和提高效率、保证一致性的模板。治理：为了确保业务分析流程得到有效和正确地执行，相关人员遵循既定的标准和相关文档，如需求文档等。企业需要有相关的治理机制，包含监督、控制、跟踪和审计。测量和分析：对每个项目的需求质量和流程执行情况进行评估、测量和分析，为需求风险管理提供相关信息，同时识别不足之处，为需求质量和流程的提高指明方向。

三、企业级业务分析框架的构建

业务分析框架应该遵循以下原则和目标：框架应以人、流程、治理和测量为中心。通过框架能够交付高质量的，可重复和稳定的需求。框架的目的是提高需求质量和工作效率，减少错误和降低成本。但在不合适的地方采用不合适的流程，或是制订和使用过度复杂的流程，不仅造成浪费，增加成本，而且使项目利益相关者对框架所带来的积极成本效用和好处产生怀疑从而降低对整个流程的信心。因此需求框架应该有足够的灵活性以适用于不同规模、特点（技术类别和商业类别）以及开发方法论或模式的项目。流程应简单实用、易于遵循，按照“傻瓜化”的原则来设计，即只需具备基本知识和经验的人员就可以执行流程。同时对于每个流程，还应该有相应的指导和模板，实际操作人员明白3W，即为什么这样做、应该做什么和怎么做。企业级业务分析框架（如图1所示）包括下列模块。业务分析基本原则：定义适用于整个业务分析流程的原则，无论是IT项目、IT维护，还是仅限于商业业务范围的业务分析,都应该采用统一的业务分析流程；业务分析流程应该采用上述用例驱动模式；技术和业务部门的利益相关者如业务专家、系统专家、开发团队和测试团队都要及早参与到IT项目的需求阶段。有时还需要系统架构、信息安全等团队的参与。需求开发：需求开发是需求流程中的核心流程之一。在基于理解客户和利益相关者需求的基础上开发客户的业务需求；建立和维护所有利益相关者对需求的共同理解；在整个系统开发生命周期中，需求被不断地识别、跟踪和细化。需求开发模块内有4个支持子件,即需求开发流程、指导、模板和培训工具。需求开发流程：第一步，收集客户的需要和愿望。业务分析师要分清客户的需要即必需的功能和客户的愿望即最好有的功能。第二步，业务分析师识别、导出、分析、合并、记录客户的高层需求（包含功能性和非功能性）。第三步，在高层需求文档诸如高层需求文件、产品分解图(PBS)、产品流程图(PFD)、背景图(ContextDiagram)、用例模型的第一个版本完成后，由主要利益相关者如客户、开发团队、测试团队进行审核。第四步，批准高层需求。第五步，项目经理或业务分析师确立高层需求的基准。第六步，在高层需求批准后，业务分析师开始底层的需求工作，基本重复上述2~5的步骤，具体的文档和内容会不同。需求开发指导：对于需求开发过程中的每个子流程或领域需要制订实践指南，以避免相关人员如业务分析师走弯路，减少错误。尤其对于大型项目，制订统一的标注和实践指南尤为重要。

需求开发模板：对于需求开发过程中的各种文档需要制订适用于不同规模、层次、复杂度和特性的项目，模板的主要目的是统一标准、减少误解、提高工作效率。需求开发培训：需求分析师的水平和经验直接影响需求的质量和业务分析流程的执行。通过相关培训，将其业务能力提升到满足企业项目的水平是提高企业效率的有效途径之一。培训不仅局限于知识的获得，而且应该覆盖流程的熟悉，工具的使用等。需求管理：需求管理是需求流程中的另一核心流程。其目的是确保所有需求管理的任务被执行并得到满意结果。项目需求流程的一致性包括形式、内容、格式、实践等。需求管理通常由项目经理和业务分析师共同完成。通过sign-off(批准)来确保需求相关文档获得主要利益相关者的批准，通过制订需求追溯性矩阵来保证需求的可追溯性，识别并管理需求流程中的不一致性，及时更新、分析由变更请求而产生的影响。业务分析风险管理：该模块是业务分析风险管理的一部分。其目的是及早识别需求中的不同流程风险，并在其不同阶段识别、消除或降低风险。需求风险管理通常由项目经理、业务分析师和其他团队共同完成。

业务分析治理：业务分析治理是整个企业IT治理的一部分。包括对业务分析流程的监督、控制、品质保证和审计。通常由独立于项目之外的多个第三方来执行。具体的组织结构和执行方式因企业的IT治理模式和架构不同而不同。业务分析测量和分析：测量和分析是CMMI中的一个流程。目的是确保管理团队审阅相关测量结果和报告，为其持续性提高采取相应更正行动。采用外部标准如CMMI来衡量流程的成熟度。测量和分析的重要部分是度量信息，包含清楚定义度量信息；有效实施度量信息；收集和分析与度量信息相关的数据，并与管理团队讨论。