2006年8月，在进行了一系列慎重接洽和考虑后，浙商银行开始按照IBM FSDM（Financial Services Data EnterpriseModel）的数据模型、逻辑模型的要求，对数据进行清理，并对业务规则进行定义。但行业模型的作用在于提供行业里的KPI以及面向主要业务分析的数据模型，基于自身业务的个性化的分析需求都需要自己做。而FSDM的仓库模型虽然在全世界130多个金融机构都部署过，但在中国大陆尚没有人采用，这意味着没人真正了解这个模型。而且国外的东西毕竟不能拿来就用，中国的实际要求远比国外复杂得多。国内外的市场情况完全不一样、标准不一样、计量的风险不一样、央行的管理也不一样，这么多的不一样足以表明这是件极具挑战性的事。

    “浙商”方略

    经验丰富的实施队伍与浙商银行化解了实际建设中的种种问题，绩效考核体系和1104工程应用都已运行，目前数据仓库平台运行的效果在宋士正看来还比较理想。这样的结果究其根本归功于浙商银行在这件事上的战略方向，这种方向则源于此前数据仓库管理信息系统建设走过的路。

    据一位不愿具名的业内人士透露，某行曾想分析信贷客户风险度，但购买完系统并实施后，才发现根本做不出来。因为在进行分析时，很多数据是关联在一起的，包括成本、贡献度，甚至包括计算机的运作效率，这不是信贷部门一家可以做成的事。这就是建设企业级的数据仓库两种最常见的失败做法之一：以局部需求驱动设计、建设数据仓库，着眼于短期利益，各部门各自为政。就像一个个小房子建好了再造高楼大厦，其难度可想而知，没有从满足整个企业的长远发展要求出发；另一种做法是贪大求全，希望一次建设完成，就管理信息系统的特点而言，其难度和可能性同样可想而知。

    那么理想的方法是什么呢？统一设计、逐步推进、一劳永逸、保持最新，这是浙商银行给出的答案。统一规划、整体架构，可以避免资源浪费；在核心架构的基础上逐步实施，不仅可以降低投入，而且可以很好地控制项目进度；一劳永逸指的是整个架构搭好以后，就可以根据需要不断向前推进。

    根据浙商银行公示的2006年年报，截至2006年底，浙商银行的总资产已达到366.13亿元，其资产、存款、贷款的增长都在60%以上，其税前利润4.08亿元，比上年增长186.51%，税后利润2.8亿元，增长328.22％。虽说这是一家不折不扣的小银行，但的确是在高速发展中。由此也就不难理解，为什么浙商银行对于数据仓库建设的期望是：一个以不变应万变的系统架构，这样系统在未来的开发时无需花费太多精力，就能满足近期和长远的需要。

    之所以选择IBM，就是因为在宋士正眼里，FSDW模型涵盖了整个金融行业整体业务方案和规则。分析认为，这样的方案和规则，在相当长的一段时间内是完全包含浙商银行或者是国内金融行业的数据指标、关联关系和业务定义的。而且基于该模型做出的整体架构是可扩展的，完全符合浙商银行的“16字方针”。定义好规则和关联关系，已有的数据就放进去，没有的先空着。这就像验收新房一样，大的架构不会有什么变化，只是按照自己的标准和想法装修即可。当然，对模型进行客户化改造和重新定义非常重要。

    同样是沿着“16字方针”的思路，浙商银行把整个数据仓库项目建设实施分为三个阶段：第一阶段是平台建设，用时9个月；第二阶段以应用为主，深化业务运营分析、多维分析运用等，计划需要2〜3年；第三阶段则主要加载进去企业的战略，包括提升业务决策支持，对操作风险、市场风险、信用风险等等进行计量监测等。

    正因为一期的顺利，浙商银行计划今年年内就开始二期工程，在现有的基础上，往前走向分析挖掘利用，比如客户关系、净资产分析、风险额度管控等。这样的方式究竟之后还能否再奏凯歌，宋士正的回答是，“我不是说我一定能成功，只是说失败的几率相对小些”。

    “中国这些客户做数据仓库管理平台其实是可以成功的，当然是选择了正确的基础和方法论。”

                                                 —IBM大中华区软件/实验室服务总监 胡晓专

    宋的自信源于项目的过程中总结出的经验，这些经验也是他人或浙商银行自己的教训。在数据质量的问题上，浙商银行就走过很大的弯路。在项目的发展过程中，银行原有的业务不能停下来，新业务当然也要推出，有时新、老业务的衔接上没有做好，就造成了数据质量、数据关联关系上的问题。不同业务系统的数据质量、规则、定义不一样，要建立一个统一的业务分析视图，就必须统一标准、统一规则、统一定义。

    经验教训让宋士正明白了：在做数据仓库信息管理系统时，一定要和核心系统同步改造，比如银行里面的核心业务处理系统、授信业务系统，并由一个统一协调管理体制来把控。这样大家就会成为一个整体，而不会形成这样一种局面：我是专门做核心系统的，你是专门做数据仓库的，各不相干。否则也许一两年以后，你会发现业务的某些东西变了，数据仓库的很多东西也随之变成无用的了。正因为感受颇深，浙商银行前一段在做项目管理方面的尝试，如建立统一的需求分析认证，让各个项目小组汇总：到底该项目会对数据仓库有什么影响，对其他系统有什么影响，共同来产生开发设计的方案，以实现统一决策。最根本的，全行信息系统的建设都必须要遵循统一的标准框架。

    在平台上搭建应用系统时，宋士正体会到的成功要素则是要坚持业务驱动，绝不能为建数据仓库而建数据仓库。在定义这些数据的规格、定义产品的分类时，一定要和业务部门共同研究，根据业务需要来设置。这样做一来可以分析出今后的管理需要，这样系统才会有效果；二来在标准怎样放进去、业务规则如何理解、究竟应该怎么分类这些事上，业务部门更有发言权。

    数据仓库最终是为管理部门服务的，如果他们没有兴趣和需求的话，建数据仓库就没有任何意义，结果只会走向失败。当然前期在建平台、搭架构的时候，由IT部门和业务部门共同驱动比较合适。但平台架构一旦完成，就必须要业务管理部门主导进行驱动，然后共同把数据仓库往前推进。没有具体的业务管理驱动，数据仓库建好了就不会有多少功能，对企业的管理层也肯定没办法交代。宋的秘诀是可以选择一些必须的、棘手的、数据源可以保证的业务系统，如绩效考核系统、净利差分析、流动性分析、授信限额等分析应用，其好处显而易见——范围小、见效快、投资回报率高。

    除了以上两点外，宋士正还总结出了以下经验：

    ★不能以部门局部需求或眼前需求为导向设计系统，必须要设计长远的整体架构。以前很多数据仓库建设失败都属于就事论事型，为一个小需求而建设一个数据仓库、设计模型，结果这个模型没有办法继续推进。

    ★必须利用数据驱动和模型驱动来同步推动整个数据仓库的系统架构建设。数据仓库建设模型把数据定义规则、逻辑模型、数据模型都已全部定义好了，但在这种情况下，也必须以架构为先导来建设基础架构。这样的架构才是可以保持一定时间、可以长远往前推进的。至于暂时不用的东西，可以逐步完成，但整个架构不会推倒。

    ★数据仓库建设好后必须往前走，这是一个长期的过程，不可能一朝一夕就全面建成，因此必须设定分阶段的实施目标，这样会给大家不断向前走的积极性。

    ★要选择开放的代表先进技术方向的方案，同时也要考虑今后的SOA架构。要让整个信息系统形成一个合理的可重用的闭环。宋的这个看法，在另一位业内人士眼中是理所当然的，因为引进先进的技术方案是为了避免失败，长远来看，一些大银行系统建设时间很长，需要SOA架构进行整合；小银行尽快设计成SOA架构，可以使信息系统今后避免很多不必要的麻烦。

    ★建数据仓库宜早不宜迟。因为没有一定的数据量是得不到比较准确的分析和挖掘结果的，有时候感觉分析结果不太正确，就是因为数据不够。而要想拥有大量的数据积累，就得早建数据仓库。

    ★因为建数据仓库是一个复杂的长期的工程，所以需要有专业的实施队伍，特别是在模型架构方面擅长。模型架构直接决定了仓库本身是否可以往前发展，是一个基础。

    回过头来看整个过程，宋士正认为最大的好处是建设了一种能不断地想、也能不断地做的平台。但他希望最美好的东西是在未来，因为前期做的其实都是基础工作，真正的考验和收获都在后面，“我们能不能走下去，管理怎么样，我们的分析结果能不能为我们的服务所用。”

转自《CIO Insight》