作者: , 出处:《管理学家》, 责任编辑: 许琳,
2007-03-23 15:58
市面上的BI厂商形形色色，国内的，国外的，价格高的，便宜的，功能强大的，简洁的，应有尽有，到底哪一款产品才适合自己的公司呢，哪一款跟公司现有系统的接口更好呢?
A公司这几年信息化的势头很好，ERP、PDM、CRM和分销软件等业务系统陆续上线。这些系统不断产出大量的数据，如何把这些抽象的数据转化成信息，使得业务人员能看懂、企业管理者能据此做决策呢?企业如何做到更深层次的、跨系统的数据分析和报表查询?商业智能(Business Intelligence，BI)或能助一臂之力!
BI之行，始于选型
市面上的BI厂商形形色色，国内的，国外的，价格高的，便宜的，功能强大的，简洁的，应有尽有，到底哪一款产品才适合自己的公司呢，哪一款跟公司现有系统的接口更好呢?A公司开始伤脑筋。
业务部门关注的是系统功能的实现，无论是国内还是国外公司的产品在这方面区别并不大，重点需要考察的是分析功能的易用性，包括对某个主题的分析维度选择的方便性，图表展现的丰富程度，以及一些简单的分析功能(例如排序)、特定数据格式改变(如变成红字突出显示)、向下钻取的方式等。对于BI前端分析的标准功能，比如向上向下钻取、多维度分析、多种图表展现等，属于BI套件基本功能，选型过程中业务部门人员可以不必过多关注。有一点需要注意，如果企业需要业务部门自己开发高级报表和分析主题，那么，自定义报表功能的易用性也将是业务部门所需要关注的。这里的易用性包括源数据字段的自定义和查找、报表的表头拖拽和维度组合，以及数据选择条件的选取三个方面。
而作为选型主力的IT部门关注的重点跟业务部门又有所不同。BI软件的实施项目和其他信息系统相比，涉及到系统接口和数据建模，往往需较大的开发量。对于一个完整的BI解决方案，需要结合企业现有业务系统的实际情况，考虑它每一部分组件的技术架构实现。
因此，选型前不妨看看完整的BI系统是什么样的。一个完整的BI系统，无外乎由ETL(数据抽取转换工具)+DW(数据仓库)+OLAP(联机分析工具)三部分构成，有的还可能包括针对复杂格式报表需求的报表解决方案，如图1所示。
ETL，取决于企业现有系统。ETL部分即数据抽取转换工具，它将业务系统中的数据抽取出来，经过数据格式转换以及清洗、合并等加工工作，最终装载到企业数据仓库(Data Warehouse，DW)中，是BI系统和其他业务系统的数据接口。选择ETL时，重点要关注的是企业现有系统的情况。如果业务系统数据结构比较简单，可以采用直接导入DM的方式，或者使用SQL Server的DTC等免费工具完成，成本较低。对于复杂一些的业务系统，比如SAPR/3、Oracle EBS等，由于其底层数据结构比较复杂，直接抽取数据库的方式难度较大，往往抽取不完全或者数据不对，采用应用层接口的方式比较可取。当然这种接口需要开发、或者单独购买解决方案。如果对时效性要求不高，也可以使用数据文件批量导入的方式，每隔一段时间从系统中导出数据文件，然后用ETL工具装载到DM中，这跟应用层接口的方式相比成本较低。ETL方案中还需要考虑的是现有系统的分布，有些大型企业，ERP系统分别部署在各地的工厂里，从这些地方抽取数据还要考虑到网络传输的问题。此外现有系统的数据质量、是否要进行数据清洗也是需要考虑的因素。总之，免费的ETL可以节省投资，但对于复杂异构系统的集成，专业的ETL工具还是首选方案。
DW是否有必要建立?业务系统的数据通过ETL处理，最终被装载到DM中。对于希望节省投资、缩短实施周期的企业，可能会考虑不建立DM，直接从业务系统抽取数据，进行OLAP分析或者报表查询。尽管现在大多OLAP和报表工具都有缓存功能。然而，在报表生成的漫长等待过程中，直接抽取数据会给业务系统的运行造成很大压力，更重要的是数据更新不能及时反映、可自定义能力差。随着业务系统数据量的增加，以及报表和分析主题的增加，DM迟早要建立起来才能满足业务需求。而项目初期建立起来的系统生命周期也将结束，投资很难得到保护。因此，在条件允许的情况下，BI项目初期就应建立DM。
OLAP和报表工具，够用就好。对于这一部分，IT人员更多的关注其技术架构。OLAP的实现不外乎有ROLAP、MOLAP和介于两者之间的HOLAP。ROLAP方式需要的内存大，而磁盘空间要求小，对于数据量较大的、较简单的数据分析来说，比较适合。MOLAP需要建立数据立方体，因此对磁盘空间要求比较高，但是从性能和灵活性上来讲要略胜一筹。具体选择哪一种，需要企业按照实际情况而定。需要注意的是，对于一般的企业，任何一种实现方式基本上都可以满足要求，因此争论哪种技术更为先进可能并没有太大的意义。对于报表工具，大多BI软件提供商都是作为独立的组件分开报价的，因此，IT部门应该评估业务部门对报表的需求，如果报表没有非常严格的格式要求，OLAP工具的分析结果就足够用了，报表组件没有必要再去购买。
BI实施须解决的三个问题
选型完成了，接下来就该关注实施了。实施还没开始，销售、生产等部门就因为谁先谁后的问题吵起来了。这些部门因为尝到了信息化的甜头，在BI系统上也争先恐后，那到底该如何确定项目实施的先后顺序，如何明确项目范围、项目目标和项目实施方法呢?
项目范围的明确BI系统的实施，并不涉及到业务操作流程，它所提供的总结分析、趋势预测，基本上都是为管理上的要求和提升而服务的。在企业内部呼声很高、决定上马BI项目的时候，往往各部门都对其寄予了很高的期望，要求其能解决大量的甚至全部的管理需求，然而这些需求基本上没有一致的。
作为分销类型的企业，A公司的产品研发部门想知道各种种类、规格或者价格的产品卖得怎么样、产品的利润率如何，以指导研发方向;而运营和生产部门想知道库存周转、生产成本的变动，以及质量控制的情况，改善低效环节，提高生产和运营管理水平;销售部门则更多地关注于各地区的销售业绩完成情况，关注客户的购买行为分析;此外还有财务部门等，都对项目有很多不同的要求。
对于金融、电信类的企业，其需求往往更为复杂。因而在企业内部发起项目的时候，往往开始就存在项目范围过大、难以实施和控制的风险。项目范围的确定，必须要遵循合理规划、分步实施、急用先行的原则，从公司战略角度出发，对于企业的核心竞争能力环节，以及管理比较规范、业务数据有积累的业务部门开始，在实施成功后，有计划地推广到其他部门和领域。在确定项目范围的过程中，还要考虑到业务数据获取的难易程度。在一些企业中，很多的业务活动根本没有系统支撑，只有手工填报的报表，这样的数据一方面很难导入，另一方面数据存在不准确、质量差的隐患，因此不应列入优先考虑的范围。
项目目标的明确即使在一个部门内部，高级管理层、运营层以及业务人员的需求也存在不一致。像A公司的销售部门，总监关注销售计划的总体完成情况、费用使用情况，重点客户的销售推进，以及部门的KPI完成情况;而产品线经理和区域销售经理则分别关注相关产品或者相关区域的运营;销售员则可能只关心自己的销售业绩完成情况，以及自己在部门内的业绩排名。细节关注的层次直接影响到BI和DM的数据抽取和模型建立。
-