全球化需求管理原则及方法

业务发展是突飞猛进的，而信息系统的建设是一个浩大的工程，是循序渐进的，不能一蹴而就，而且需要投入大量的人力、物力和财力。无论多么灵活的系统架构、多么敏捷的开发模式，系统建设也不可能完全无缝响应业务发展的所有要求。

特别是对于全球化系统建设这样一个庞大的系统工程来说，需求管理就显得更为重要了，主要的需求管理原则和方法如下：

（1）建立专门的需求统筹和需求管理部门

需求管理部门要有绝对权威，对行内业务需求有认识高度，负责建立、完善业务需求统筹管理流程、审核机制和优先级排序机制。全球化系统建设的需求范围涉及行内各个业务领域，每个业务领域从自身发展角度，在遵从集团战略发展部署的前提下，都有各自的业务发展规划，这些业务发展要求都需要信息科技的支持，所以很容易形成对科技资源的争夺。

这时，就需要建立一定的规则和制度，站在集团发展战略的角度对各条线部门的需求、跨业务领域的需求进行整合和统筹，并对业务需求的优先级进行把控，对需求基线进行管理，为IT资源的合理投放提供依据。建议设立专门的岗位角色—业务分析专家，负责业务需求开发和需求管理工作，这个角色介于纯粹的业务人员和技术人员之间，既294要拥有丰富的业务底蕴，也具备一定的架构设计能力，同时还有丰富的实战经验，是业务人员和技术人员之间的沟通桥梁。

简而言之，在全球化信息系统建设的过程中，要做好需求管理，第一步需要在组织架构方面给出清晰明确的定位，以及管理层的支持和授权。

（2）建立需求准入制度

有了明确的定位和正式授权之后，需要管理部门为需求统筹和整合制订规则，只有符合这个规则的业务需求才有可能被纳入信息系统的建设规划。

原银行系统内已设有海外分行的，首先要求满足对海外各分行现有旧线系统功能的覆盖，不能造成业务后退和客户服务质量降低。其次要满足各国当局监管提出的强制要求，并在整体项目范围和计划可控的前提下，对于现有业务功能流程必要性的提升和优先级较高的新增功能需求也可以纳入。对于信息系统建设暂时不能满足的业务功能，技术部门和业务部门需要共同制订业务手工绕行方案，在大方针的指导下，在一定时期内业务发展有必要为系统建设让路。

通过对业务流程的梳理，将旧线系统和新线系统的功能实现逐项进行差异分析和比对，并根据上述的需求准入原则，对差异项的结论进行落实，最终形成系统建设业务需求基线。

（3）制订合理可行的需求划分方法

商业银行全球化的信息系统建设，会涉及行内几乎所有的IT应用系统的替换或者升级改造，从核心业务系统到渠道平台、从各式各样的外围产品系统到后线统计分析系统。那么业务需求该怎么提出、怎么分割呢？是完全按照业务领域划分，按照业务思维进行需求编写，还是按照IT应用系统划分，从技术建设角度来编写需求呢？两种方式都各有利弊，纯粹从业务角度出发编写出的系统需求，需求相对完整，但势必会涉及IT系统的交叉改造，导致IT系统的版本关联复杂，项目管理成本太高。若完全从IT应用系统的维度编写需求，应用系统版本关联度高的问题解决了，但是业务需求却被割裂了，业务流程不完整，需求跟踪管理难度大，测试验证时也难以实施。

于是，从项目范围便于切分、应用系统版本关联松耦合以及业务主管部门对需求完整管理等几个方面综合考虑，笔者建议采取一种折中的方式。即在业务差异分析和需求开发阶段，就由业务人员和技术人员共同将涉及技术改造的差异项落实到每个应用系统中，形成业务需求和应用系统的对照映射关系表。这样，无论是从业务维度提出的需求，还是应用系统维度编写的需求，都能在对照映射表中进行追踪维护。(www.xing528.com)

在实际运用中，可以通过多轮次海内外差异分析的沟通探讨以及论证，将涉及技术改造的差异点逐项落实到每个应用系统中，再由需求管理部门组织跨业务条线的沟通，整理形成每个应用系统的海外建设业务需求。即在每一个海外批次，一个应用系统仅提出一份完整的业务需求。

对于跨多个应用系统的重点和难点需求，则通过建立不同的业务专题和技术专题，在各个项目间建立需求关系表进行关联，并在项目实施的各项工程活动中通过走查、评审等多种方式持续跟踪管理，保证这种跨多个应用系统的需求能够被完整实现，而不被遗漏。

（4）需求变更严格审核

需求管理是决定软件项目开发取得成功的关键，贯穿着软件项目开发的全部生命周期，其主要目的是在客户与实现客户需求的项目人员之间达成对需求的共识，维护需求与工作产品和产品组件的一致性，并控制需求的变更。

尽管制定了严格的需求准入制度，设定了需求封版时间，但是项目过程中总不可避免地会进行需求变更，例如当局监管法规的调整、配合国家金融战略发展建设、满足银行大客户的个性化要求甚至是前期工作中遗漏的业务要点等。变更管理的目的并不是要拒绝需求，也不是要将需求变更控制得越少越好，要认识到特定需求的改变是不可避免的。当变更出现时，要对需求变更的背景进行分析，对其带来的影响进行评估，如需求变更是否合理必要、是否会导致在运行的项目延期、是否会导致项目费用的超出、是否会导致项目范围大幅度的变化。

前面提到本书建议海外信息系统建设的需求基线按照IT系统的边界进行划分，但是需求变更是由事件驱动，因此需求变更的管理不能按照IT系统竖向切分，而要通过业务部门视角横向提出，不再限制在单个应用系统中。在对需求变更实施时，会落实到一个应用系统项目牵头管理，将变更涉及的所有应用系统通过内部任务安排的方式进行统一管理。这样的需求变更管理方式，最大程度上减少了变更涉及的项目范围，也能够使需求变更管理在一个项目范围内可控，需求的跟踪追溯性也更高。

（5）建立需求管理平台进行需求变更的管理和追踪

目前，业界还没有规范的方法和技术来系统管理需求的变化，在实际项目操作过程中，要么基于需求管理人员的经验和水平来进行需求变更的手工管理，要么利用一些工具来协助需求管理人员进行变更的跟踪。

市场上有很多辅助需求管理的工具，国内常用的商用需求管理工具主要有IBM公司的Rational DOORS、Rational CQ、Rational公司的RequisitePro、Technology Builder公司的CaliberRM等，或者银行自身开发的内部管理平台，实现对行内业务需求的管理，将需求基线以及需求变更对项目的影响全面分析并跟踪管理起来。利用需求管理平台，可以为需求属性管理、基线管理、需求变更管理、需求跟踪与追溯等需求管理主要内容提供帮助，对需求管理人员手工工作的效率有极大提升。需求管理平台甚至可以将非结构化的业务需求，通过模版化、标准化的加工，识别成结构化的需求项，再由技术分析人员针对每一项需求项，制订和分析设计技术实现方案，并在平台上进行应用系统范围的管理，以及工作量的评估，并且可以通过需求管理平台将需求与分析、设计、实现、测试进行有效的结合，并作为项目管理、任务管理工作的有力支撑。

需求管理平台除了应用在单项需求的管理和跟踪上，有手工管理所不能媲美的长处之外，对于行内业务需求的管理和信息系统建设水平的提高也是非常有促进作用的。通过一定的积累可以利用平台实现业务需求复用，减少同类需求的重复编写工作量，也可以避免重复建设和需求相悖的问题出现。通过对需求数据的统计，可以形成银行业务需求全景视图，以及各个维护的筛选和分析。

总而言之，全球化的银行信息系统的需求管理与常规软件工程区别不大，业务需求复杂多变，管理方法也必须灵活适应，万变不离其宗。