数据仓库案例解析：合理看待数据价值

银行在经营过程中积累了海量的数据，而且随着业务系统的扩展及规模扩张，数据的增长也表现出了超常规的速度，数据仓库技术的出现，为有效地利用这些数据提供了重要手段。

一、数据仓库应用的两大主题

       数据仓库的应用从大的方向可以概括为两大主题。

       一是数据管理上的应用。它的作用和价值主要体现在对数据的深加工和分析上。数据仓库的建立规范了业务部门的数据流格式，打通了系统内数据的联系。通过数据的应用，将各种业务数据按事先确定的主题进行抽取、转换、加载等处理，从而建立规范统一、高度共享、性能稳定及具有扩展性的综合性数据仓库系统。

       二是数据统计分析上的应用。随着银行经营精细化发展的要求，无论是银行自身还是监管部门，对于数据的采集、存储、信息发布及统计分析要求越来越高。银行的不同部门、不同层次的领导都需要提供灵活的动态查询工具，提供简单易用的，可即时生成各种复杂计算和格式的报表工具，以及从多角度、多层次来分析数据的工具，以发现业务在不同角度的特征。更高层次的应用希望提供预警系统，达到监控和预测风险的目的。

       在数据统计分析应用方向上，层次化特征非常明显，向高层需求者表现的是高度的提炼、概括、体现的是趋势。向下的分析层则是高度的细化、具体、体现的是量化特征。

二、数据仓库应用案例：绩效考核系统开发

       通过以下一个绩效考核系统开发的案例分析也许能对大家有所启发。

       1. 案例背景

       银行的绩效考核是核心，它也是激励员工发展，实现自身价值的重要手段。因此，各家银行都将它作为数据仓库应用的重点。现有绩效考评方式，数据来源分散，手工操作误差大、经常出错；同时，很多绩效考评分小指标由客户经理自行上报，数据统计工作量很大，而且准确性不高。

       为减少差错，提高工作效率，很多银行都在开发基于数据仓库的绩效考核系统。但是其中也存在不少难点：

       （1） 需求分析困难，业务部门根本没有提出明确的需求，而本单位的考核办法许多细节没有明确，关键信息遗漏；需求模糊，这给需求分析带来很多困难，比如：“就高不就低，听话的不吃亏”；各个部门观点不一致，不知所从。

       （2） 考核指标变化太快，在系统设计当初，系统设计师已经尽量做到各项考核指标参数化，这样当单项指标发生变化，系统不至于有大的改动；可是单位为了各项业务的快速推动，使得指标变化太过频繁，有些甚至是考核方法的变化，这给系统设计带来很多苦恼。

       2. 开发思路

       （1）业绩核算。员工的营销业绩核算是绩效考核系统的基础功能，一般来讲，最直接的方式是以创造利润来核算。但由于银行经常需要根据自身的业务结构、资产结构、监管要求等需要对业务发展方向做一些微调，在一定时期内鼓励某项业务品种的发展，因此引入了“模拟创利”的概念。即考核员工以完成模拟利润为标尺，根据阶段性业务发展方向目标，通过模拟利润系数来调整业务发展方向。

       在原始交易系统中，对于每一笔交易，都对应了唯一的客户经理代码，而各个业务品种相对来讲差异非常大，所开发的系统必须分期完成，首期重点是放在大的业务品种方面核算业绩，后期逐渐完善。

       开发的系统可以按产品树逐层展现机构或员工的模拟利润的相关数据，它的数据源来自于客户经理营销业务在交易系统中的统计，如余额、增量、日均数等，而对于最终需要考核的“模拟利润”这一数值，则通过考核委员会核定的系统加以转换。此类报表的服务对象有营销部门负责人、业务营销人员及普通员工，部门负责人在这里能了解到本部门整体的业务情况和每位成员的业绩，总的来说它显示的数据是比较微观的。

       （2）在基础的业绩计算后，对数据进行超越部门的统计和分析是必需的，在排名模块中，展现的报表服务对象是一些管理部门，这些数据经他们处理后可能会出现在某个报告中提供给分行决策部门。

       例如：规模增量排名，以绝对增量或百分比显示机构或员工的业务增量排名，并以颜色变化形象显示排名变化

       业务规模分解：以柱形图显示一级指标数据,以饼图的直观形式显示一级批标的分解效果,通过这个分解能够直观看出该行的业务构成比例。

       （3）在现有的交易系统中，由于仍有一部分业务数据分散在靠手工记录的台帐中，没有它们数据就不完整。在绩效考核系统开发中，如何把这一部分数据管理起来，提高它的准确性、合规性则显得比较重要。例如：票据收入、中间业务收入、银行承兑。

       台帐主要是完成各类数据补录，这部分数据的特点是录入繁琐，工作量大，但又是业绩计算中不可或缺的一部分，所以这部分开发工作的重点应该是以追求现在数据的批量导入做为目标。这部分数据也有专门的报表，使用对象是与这些业务相关的营销人员。

       当然，以上这三个角度的开发思路只是一个案例，而在实际应用中，各个系统都有它自己的特点和功能，而这些特点的表现，其实是根据考核办法和考核维度所决定的。

三、合理看待数据价值

       通过以上案例，可以做这一个比喻：银行在经营中，交易系统产生的原始数据，就好比是种植的小麦。原始数据进入数据仓库需要进行集成，即所谓的“ETL”过程，它好比就是将小麦加工成为各种等级的面粉。而基于数据仓库开发出的应用系统，比如以上案例分析中的绩效考核系统，就好比消费者（应用系统使用者）所需要的面食，可能是面包，也可能是馒头、花卷、大饼。由于消费者的偏好（即应用系统使用者要解决什么样的问题？他的关注点在哪里？）不同，应用的开发方向当然也一定要随之而变，就像是加工面粉的流程必然不同。

       当然，数据从交易系统到数据仓库到数据集市进行不断整合和信息派生过程中，会丢失一些细节信息，就好像已经看不到小麦原来的形态。因为交易系统考虑如何记录特定业务流程，数据集市考虑如何回答特定分析需求，而数据仓库则需要考虑如何归纳和记载数据的历史轨迹。

       还有一点可能表现得更为隐蔽，那就是应用的使用者在使用过程中，不只是单纯地体现了数据的价值，享受到了数据应用的益处。同时，成熟的应用使用者也会很容易地“派生”出新的数据需求、应用需求，这一需求可能需要进一步的数据挖掘与开发，也有可能会引发变更原始交易过程、补充原始交易要素给以补足，也就是说它会反过来对交易系统产生新的需求，当然这必将是一个良性循环。
 

扫码即可手机
阅读转发此文