BI

转贴自  http://sysapp.51cto.com/art/200704/44152.htm

 

探询BI成功的秘诀

BI之行，始于选型

市面上的BI厂商形形色色，国内的，国外的，价格高的，便宜的，功能强大的，简洁的，应有尽有，到底哪一款产品才适合自己的公司呢，哪一款跟公司现有系统的接口更好呢？

业务部门关注的是系统功能的实现，无论是国内还是国外公司的产品在这方面区别并不大，重点需要考察的是分析功能的易用性，包括对某个主题的分析维度选择的方便性，图表展现的丰富程度，以及一些简单的分析功能(例如排序)、特定数据格式改变(如变成红字突出显示)、向下钻取的方式等。对于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的数据抽取和模型建立。

首先是粒度，要追究到每个销售员每一单的销售明细，和最多关注到每个办事处每天的销售额，DM的数据处理量就会相差很多。另一个方面是维度，BI系统的主要功能实现就是多维度分析，比如分析某种产品在某个地区某个时间的销量，在这个模型中，产品、地区、时间就构成了分析维度。有些业务部门，尤其是产品研发部门，往往希望能考虑尽可能多的维度，比如在刚提到的销量分析模型中，除了常规的产品维度，产品部门还想看到颜色、品类等因素对消费者购买行为的影响，而这些维度的分析能否在BI系统中实现取决于两个方面。一是这些维度的信息是否在业务系统中已经录入和存在?如果不存在，那么就没有实现的可能，BI系统不能产生业务数据，只能分析业务数据。

二是维度直接影响数据模型的建立和IT基础设施的建设要求，每增加一个分析维度，模型更为复杂，给系统增加的复杂性是几何级数，这意味着原来四小时可以完成的数据处理可能就要延长到6～8小时才可以完成。然而，难以解决的是企业缺乏对业务影响因素的分析。实际上，目前企业都还没有很完善的业务模型，某个因素对做决策的影响到底有多大，以什么样的方式影响，说不清楚。如果在商业逻辑上都没有解释清楚，很难建立有说服力的模型。因此，在项目开始的时候，通过讨论，使业务部门明确可以解决的问题有哪些、可以解决到什么程度，是保证用户满意度、项目实施成功的前提条件。

实施方法BI系统不存在大量的业务流程，因而不会带来巨大的企业变革风险，因此实施方法相对容易。BI的实施过程重点，一个是用户需求的调研，另一方面是数据质量保证。需求调研和分析在项目实施过程中占到了约40%的工作量。在项目范围和项目目标明晰之后，用户需求分析的难度就降低了不少。有行业经验的实施顾问会清楚业务领域的商业逻辑，将行业经验和用户具体需求结合，将会提高需求分析的速度、快速建立模型。IT项目的实施过程中，用户需求的不确定性很大，模型的建立肯定是一个反复沟通和修改的过程。

持续改进，挖掘BI潜能

BI的建设是一个长期的过程，随着企业业务的变化，导致业务部门用户需求的变化，甚至是业务系统的升级，都会对BI系统的建设造成影响。如何进一步提高BI的应用水平呢?主要包括两点。

建立企业基础数据管理机制

A公司的业务系统有了，BI也上了，可是却开心不起来，因为发现有些模型分析出来的数据跟实际偏差很大，不能使用，还要手工去改。到底为什么呢，问题可能就出在数据管理机制上。

首先是数据定义的问题。一方面，同一个字段，不同的填报人员或者不同的业务系统统计口径不一致。比如销售额，有些地方填报的是批发给渠道的口径，而有些地方则可能理解为是渠道卖出到最终消费者的口径，不同口径的数据进行合并、排序和其他分析，结果肯定是错误的。另一方面，同一个字段，录入格式没有统一定义。举个极端的例子，一条订单记录里是“北京某某公司”订购了多少东西，而另一条记录里的同一个客户，名字却变成了“某某有限公司”，“北京”两字不见了，却又多了个“有限”，同一个客户的销售订单数据BI系统无法合并、分析，只能是经营分析人员手工完成。要解决这个问题，企业必须建立数据字典，明确在不同系统、不同报表之上的全局字段定义，避免口径不一致;同时规范每个字段的格式，避免无法合并的情况。还要建立起数据变更的规范制度，保证数据的安全，最终保证BI的数据质量。

数据管理机制，还包括数据收集的体系。对于大多数企业来说，很多的业务数据还是以手工填报的形式收集上来的。很多企业的经营分析人员把大量的时间用在催缴数据、统一数据格式上，这是十分低效的做法。事实证明，在业务系统支撑有限的情况下，建立起完善的数据收集体系是提高数据收集效率、减少错误的最佳方法。一个完整的数据收集体系，包括数据收集的模版制作和管理、数据收集的流程、以及数据收集的绩效考核机制。

建立明晰的商业分析逻辑模型

现代企业的管理，追求以绩效考核的方式驱动企业战略目标和计划的达成，从而引出了企业绩效管理(EPM)的概念。企业的战略目标，可能最终都分解到了每一个部门和每一名员工相关的KPI上。而企业、部门和员工的KPI的完成情况，直接关系到企业战略目标的实现。BI系统有能力进行KPI的分析和计算。然而，要想使KPI真正有效，BI系统真正发挥作用，KPI指标就必须可以衡量、可以逐层分解。比如评价客户满意度，就只需要关注订单执行效率和订单处理速度，而订单执行效率的达成则跟及时交付、数量精确度和退货率有关，这三个因素的量化可以通过及时交付订单率、精确数量订单数、退货率三个指标来实现，这些都可以在BI系统中实现，如图3所示。这样，抽象的客户满意度指标就可以衡量了。建立可衡量的企业战略目标和KPI体系，在BI系统的辅助下，可以动态监测，及时处理异常，保障企业战略目标的实现，从而发挥更大的价值。

除了回顾，BI还要担负预测和决策支持的角色。大部门BI系统都声称提供了数据挖掘和预测的能力。然而，数据挖掘和预测都需要相关的数学模型做支持，比如销售预测、客户流失预测等。预测模型往往需要企业多年的积累，还要考虑各种因素。因此要进行数据挖掘和预测，需要企业在实施了BI至少两年左右的时间后，有了一定的数据积累，而且数据质量稳定的情况下，由业务人员和行业专家共同搭建模型，最终在BI系统上实现。

对于A公司而言，要想用好BI这个强大的工具，就得从企业自身的情况出发，既要考虑与现有的业务系统(ERP、CRM等)之间的接口，又要从实际的需要出发，选择适合自己的BI系统，做好实施的规划和分析，并且持续不断地改进和提高。惟有如此，BI的强大潜能才能为企业所用，转化成巨大的商业价值。

 

商务智能(BI)的四大关键技术

商务智能是一套完整的解决方案，它是将数据仓库、联机分析处理(OLAP)和数据挖掘等结合起来应用到商业活动中，从不同的数据源收集数据，经过抽取(Extract)、转换(Transform)和加载(Load)，送入到数据仓库或数据集市，然后使用合适的查询与分析工具、数据挖掘工具和联机分析处理工具对信息进行处理，将信息转变成为辅助决策的知识，最后将知识呈现于用户面前，以实现技术服务与决策的目的。

商务智能的四大关键技术

商务智能的支撑技术主要包括ETL(数据的提取、转换与加载)技术和数据仓库与数据集市技术、OLAP技术、数据挖掘技术与数据的发布与表示技术。

1.数据仓库技术

实施BI首先要从企业内部和企业外部不同的数据源，如客户关系管理(CRM)、供应链管理(SCM)、企业资源规划(ERP)系统以及其他应用系统等搜集有用的数据，进行转换和合并，因此需要数据仓库和数据集市技术的支持。

数据仓库(Data Warehouse)是指从多个数据源收集的信息，以一种一致的存储方式保存所得到的数据集合。数据仓库创始人之一W.H.Inmon的定义为：“数据仓库是一个面向主题的、集成的、稳定的、包含历史数据的数据集合，它用于支持管理中的决策制定过程”。在构造数据仓库时，要经过数据的清洗、数据的抽取转换、数据集成和数据加载等过程。面向不同的需求，对数据进行清洗以保证数据的正确性，然后对数据进行抽取，转换成数据仓库所需形式，并实现加载到数据仓库。

数据仓库是一种语义上一致的数据存储，充当决策支持数据模型的物理实现，并存放企业战略决策所需信息。数据仓库的数据模型有星型模式、雪花模式。星型模式最为常见，有一个包含大批数据并且不含冗余的中心表，每维一组小的附属表。雪花模式中某些维表是规范化的，因而把数据进一步分解到附加的表中，模式图形成了类似雪花的形状。对数据仓库的研究集中在数据集成中数据模式的设计、数据清洗和数据转换、导入和更新方法等。

数据仓库通常是企业级应用，因此涉及的范围和投入的成本非常巨大，使一些企业无力承担。因而，他们希望在最需要的关键部门建立一种适合自身应用的、自行定制的部门数据仓库子集。正是这种需求使数据集市应运而生。数据集市( Data Mart) 是聚焦在选定的主题上的，是部门范围的。根据数据的来源不同，数据集市分为独立的和依赖的两类。在独立的数据集市中，数据来自一个或多个操作的系统或外部信息提供者，或者来自在一个特定的部门或地域局部产生的数据。依赖的数据集市中的数据直接来自企业数据仓库。

2.联机分析处理技术(OLAP)

联机分析处理(Online Analytical Processing ，简称OLAP) 又称多维分析，由EF Codd 在1994 年提出，它对数据仓库中的数据进行多维分析和展现，是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据更深入了解的一类软件技术。它的技术核心是“维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。

进行OLAP分析的前提是已有建好的数据仓库，之后即可利用OLAP 复杂的查询能力、数据对比、数据抽取和报表来进行探测式数据分析了。称其为探测式数据分析，是因为用户在选择相关数据后，通过切片(按二维选择数据)、切块(按三维选择数据)、上钻(选择更高一级的数据详细信息以及数据视图)、下钻(展开同一级数据的详细信息)、旋转(获得不同视图的数据) 等操作，可以在不同的粒度上对数据进行分析尝试，得到不同形式的知识和结果。联机分析处理研究主要集中在ROLAP(基于关系数据库的OLAP) 的查询优化技术和MOLAP(基于多维数据组织的OLAP) 中减少存储空间和提高系统性能的方法等。

　　3.数据挖掘技术

与OLAP 的探测式数据分析不同，数据挖掘是按照预定的规则对数据库和数据仓库中已有的数据进行信息开采、挖掘和分析，从中识别和抽取隐含的模式和有趣知识，为决策者提供决策依据。数据挖掘的任务是从数据中发现模式。模式有很多种，按功能可分为两大类：预测型( Predictive)模式和描述型(Descriptive)模式。

预测型模式是可以根据数据项的值精确确定某种结果的模式。挖掘预测型模式所使用的数据也都是可以明确知道结果的。描述型模式是对数据中存在的规则做一种描述，或者根据数据的相似性把数据分组。描述型模式不能直接用于预测。在实际应用中，根据模式的实际作用，可细分为分类模式、回归模式、时间序列模式、聚类模式、关联模式和序列模式6 种。其中包含的具体算法有货篮分析(Market Analysis)、聚类检测(Clustering Detection)、神经网络(Neural Networks)、决策树方法(Decision Trees)、遗传算法(Genetic Analysis)、连接分析(Link Analysis)、基于范例的推理(Case Based Reasoning)和粗集(RoughSet)以及各种统计模型。

OLAP 与数据挖掘的区别和联系是：OLAP 侧重于与用户的交互、快速的响应速度及提供数据的多维视图，而数据挖掘则注重自动发现隐藏在数据中的模式和有用信息，尽管允许用户指导这一过程。OLAP 的分析结果可以给数据挖掘提供分析信息作为挖掘的依据，数据挖掘可以拓展OLAP 分析的深度，可以发现OLAP 所不能发现的更为复杂、细致的信息。数据挖掘的研究重点则偏向数据挖掘算法以及数据挖掘技术在新的数据类型、应用环境中使用时所出现新问题的解决上， 如对各种非结构化数据的挖掘、数据挖掘语言的标准化以及可视化数据挖掘等。

4.BI 的表示和发布技术

为了使分析后的数据直观、简练地呈现在用户面前，需要采用一定的形式表示和发布出来，通常采用的是一些查询和报表工具。不过，目前越来越多的分析结果是以可视化的形式表现出来，这就需要采用信息可视化技术。

所谓信息可视化是指以图形、图像、虚拟现实等易为人们所辨识的方式展现原始数据间的复杂关系、潜在信息以及发展趋势，以便我们能够更好地利用所掌握的信息资源。随着Web 应用的普及，商务智能的解决方案能够提供基于Web 的应用服务，这样就扩展了商务智能的信息发布范围。作为基于Web 的商务智能解决方案，需要一些基本的组成要素，包括基于Web 的商务智能服务器、会话管理服务、文件管理服务、调度、分配和通知服务、负载平衡服务和应用服务等。

------------------------------------------------------------------------------------------------------------

简析商务智能系统的生命周期

 

商业智能系统的建设是一个复杂的系统工程，需要一套完善的方法作为指导。下图描述的是基于多维建模的商业智能系统开发生命周期。

整个系统生命周期是以项目规划作为起点的，这个阶段需要做的是：评估组织本身是否具备实施商业智能的条件，确定系统的规模和范围，规划各种资源并启动项日。第二步是进行企业需求定义。一个商业智能项目的成功不是取决于技术，而是取决于它是否将重心放在实际的商业过程上，是否能够为商业决策提供支持。系统的设计者应该了解企业的需求并将这些需求转化为系统需求。

完成了企业需求定义后，接下来要做的是技术方案设计，数据设计以及分析应用设计，这三者在一定程度上可以并行。技术方案设计将建立一个技术框架，从而将各种技术进行整合。通常它会列出一系列的商业智能相关产品，通过一定的标准，对这些产品进行评估，做出最后的选择。数据设计包括多维模型设计，物理设计以及数据加载。先将企业需求转化成多维模型，再根据多维模型设计物理模型。在进行物理模型设计时通常要考虑聚集，索引，分区等策略，以满足工作效率的要求。最后是数据抽取、转换、加载(ETL)，建立实际的数据仓库。

分析应用设计和开发将根据企业用户数据分析方面的需要，设计一系列功能模块，提供查询与报表，OLOP分析，即席分析以及数据挖掘等工具，使用户能够方便的访问到所需的数据，并进行相应的处理。当以上三项完成之后，就可以进入发布阶段，将系统提交用户使用。同时要提供必要的支持与培训。

维护阶段包括对系统进行小的调整，对出现的错误的及时更正，对用户的培训，以及其他保障系统正常运行的各项工作，并为未来系统升级做准备。

项目规划与管理

项目规划与管理包括可行性评价，项目范围划定，效益评价，人员配置，制定项目计划的等。可行性评价:同其他信息系统一样，商业智能系统建设之前需要进行可行性评价。主要从5个方面进行：

(1)项目是否有一个强有力的发起者
这个发起者必须对商业智能将对企业带来的潜在影响有清晰的认识，并对该项目充满信心。他必须在企业中有足够的影响力和说服力，能为系统建设提供良好的环境。

(2)企业是否具有一个强烈而迫切的驱动力
这种驱动可以是来自企业外部的(如竞争因素)，也可以是来自内部的(如解决并购中出现的跨企业绩效分析)。商业智能项目不应该只是锦上添花，而更应是雪中送炭。应该用它来解决企业所面临的棘手问题。

(3)技术、数据、资源上是否可行
三者之中，数据因素最为关键。我们是否能从现实的业务系统中搜集数据，决定了商业智能系统的成败。

(4) IT部门与企业的关系是否融洽
技术人员是否明白并且尊重企业业务人员的工作;企业业务人员是否理解并且尊重技术人员的工作?如果不能做到彼此尊重、理解、并互相配合，项目进行过程中必定会遇到相当的障碍。

(5)企业当前的决策方式
企业领导者是习惯于根据事实和数据做出决策，还是靠直觉和经验作决策?一个习惯于数字的企业更容易接受商业智能的概念。当然，如果企业还不具备这一点，那么，正是利用这个项目改变人们思维和决策方式的很好机会。
从以上5个方面展开可行性分析，明确企业所处状况，评价建设商业智能系统的条件是否成熟。在这5方面中，强有力的发起者最为关键，它决定了项目是否可以实施。

项目范围划定

确定项目可行后，接下来应划定项目范围。这就需要在有用性和可管理性两方面做出权衡，把注意力集中在那些迫切需要解决的问题上。首次实施商业智能项目即将不同地区、不同业务系统、不同用户以及不同的分析需求包含进来，容易造成项目失控。

效益评价

估计商业智能项目能够为企业带来的收益和增加的成本。收益包括财务收益，收入或利润增加等显性收益以及其他隐性收益:成本包括硬件/软件的购置成本，系统维护成本等。商业智能系统的运营成本不会因为系统的成熟而大幅降低，而是会保持在一定水平上。

人员配置

商业智能项目的顺利推进，需要一个由业务人员以及IT技术人员共同组成的团队。通常角色包括：

(1)发起人：他是商业智能系统的最终用户，同时也是项目最有力的支持者。
(2)企业领导：代表企业业务部门与项目经理就具体事宜进行沟通。
(3)企业用户：系统的最终使用者。
(4)业务系统分析师：发现企业业务需求并把这些需求转化成技术框架需求，数据需求以及分析应用需求。
(5)业务主题专家：熟悉业务系统数据的含义、用途，知道数据在哪里容易出现不一致。这些知识在构建数据模型和分析可能应用的过程中非常重要