2005年开始，有关报道宣称中国的商业智能（BI）市场在IT领域炙手可热，引发众多管理软件企业摩拳擦掌，在这新的利润增长点上跃跃欲试。但事实上，至于今说
“
BI逐渐火起来
”
说两三年，用户的BI项目实施却没看到有实质性的进展。
今年8月，《经理人》杂志一篇《解析商业智能失败的根源》中提道，据相关统计数字显示，在国外，投资建设BI的企业有60%～70%以失败告终；而在中国，这个数据可能会更高。其中的原因有很多，比如缺乏历史数据支持、理解上存在误区等等。《三位一体的商业智能
—
管理、技术与应用》的作者王茁先生在与CIO INSIGHT杂志记者交流也谈到商业智能项目确实有着很高的失败率。他说这也造成了现在普遍存在的对于商业智能的两种极端的观点
——
万能论和无用论。该篇采访在8月1号被刊发于网上。
笔者从事BI的几年工作实际也证实了BI确实难以成功。失败的根源，众说纷纭，大致有以下。一是实施过程难控，如不致陷入贪大求全的项目整体规划与分步实施、需求提炼、数据质量控制、针对非技术人员设计出简便而形象的用户界面等；二是协调配合难度大，如王茁先生认为大型的BI项目需要多个部门的认真配合，如导入源数据到数据仓库这么一个简单环节都会同时牵涉到众多部门的参与。三是，一把手支持力度不够，参与BI的业务人员级别低以及投入不高。四、BI系统上线后的使用者数量少且不专业。
也许不能臆断这些BI应用都是失败的。但是BI没有达到用户和厂商宣称的结果却是不争的事实。
笔者也和其它BI从业人员一样，反思问题寻找原因。笔者认为，BI当前有六宗罪，导致了BI的高失败。即在意识和认知层面的
“
体系不清、方向不明
”
，在执行和操作层面的
“
数据不准、应用不实
”
，在基础层面的
“
全程不通、工具不全
”
。如下图所示。
罪一：体系不清，鸡对鸭讲，无法公正地相互理解以建立统一的BI认知
以下问题广泛存于各种BI项目中，主要原因是BI体系不完整和BI厂商和代理商的宣传诱导。各BI厂商的差异化营销策略形成了
“
差异化基础上的差异化
”
，而不是
“
标准化基础上的差异化
”
。由此导致了用户和开发者之间的沟通交流受阻，甚至是单方面的诱导用户的沟通。根本原因，还是在于BI
“
体系不清
”
未能给用户和集成商建立起一个标准化的认知平台。
用户：BI实质是什么，应该如何理解BI?面对众多的BI产品及其不同功能的版本，我们应该选择什么样的BI产品才能适合本企业？BI建设应该做成什么样？对于本企业的BI如何评估难度和深度并据此考虑经费、周期等问题？未来本企业做BI还应是怎样？
开发者和集成商：如何能将我们的概念融入用户的意识？怎么样向其介绍BI才能相互和谐？如何和用户共同发掘需求并顺利推荐相应的产品及其功能？如何让客户理解本次BI项目的难度而不至对支出
“
讨价还价
”
？
面对上述实际问题，用户和开发者集成商却难以达成一个利于BI长期发展的认知。原因在于当前BI体系不清晰，对BI的理解也不一致。
当前的BI体系，侧重于技术角度以详略不等的程度体现了BI从数据到应用的过程。IBM增加了该过程的管控和安全。美国数据仓库研究院展示了BI的结果对策略和行动的关联和影响。这些BI体系全面性和贴近应用性有所不足，或者用户不能深入理解，只简单的仅将BI当作利用数据的过程；或者开发者只知BI实现过程而难以明白实现结果以及原因，以致无法达到用户和开发者之间的顺畅交流。事实上，当前的BI体系仅解决一个方面的问题，即如何做BI，这仅是体用关系中
“
用
”
的其中一部分。可见当前BI体系的不完整和片面性，以至于它难以解决用户期望的BI是什么和为什么，以及BI有什么类型，BI要做成什么样？BI后期如何提升等问题，因而无法顺畅实现开发者和用户的沟通。此部分内容可详见本人博客《商业智能（BI）的哲学思索---BI框架体系探讨》。
当前商业智能也存有多种概念。从概念提出至现在，数年来对BI仍没有一个公认的统一的定义。Gartner Group、IBM、Microsoft、IDC、SAS、Business Objects、Cognos、Teradata、Oracle、MicroStrategy、all-BI述定义大致可分为三类：第一类软件论或技术论，认为商业智能是一套帮助企业管理或决策的系统。第二类技术和软件结合形成的概念和方法。第三类则多是自动化管理过程。综合上述商业智能的定义，都揭示了商业智能的技术性特性，部分观点也点明了商业智能与管理的联系。但是，他们都缺乏明确的本质性揭示和实施方法的体系化思考，既不能让人深入、全面的理解，更无法让人实现操作。可参见本人博客《商业智能的
“
操作性和提升性
”
转换----商业智能（BI）的三维框架》。
另一方面的原因，当前对BI概念和BI体系的描述不易让用户和更多的开发者集成商理解，不够直白，也容易造成大家理解BI进入误区，不好造就一个轻松交流的平台。比如有人认为业务流程改进(BPI)比业务流程再造(BPR)更适合于当前国内大多数企业的信息化及人员素质现状，因此直白地解释为
“
不坐电梯走楼梯
”
。这种直白确实容易让大众理解，相反太IT化太针对性的BI描述却难以让用户和技术开发者直接接受。这正如王茁先生认为的当前对BI的概念太窄化了，不易普及。
罪二：方向不明，好钢没有用到刀刃上，难以引导BI实现预期目标
BI以数据驱动为方向，还是以业务驱动为方向？这个问题日益受到重视。即使是以业务驱动为导向，还是会滑向数据为核心，这是为什么？
王茁先生指出商业智能发展到现在所存在的问题是人们往往过度强调
“
智能
”
，却忽视了
“
商业。商业智能变得越来越像一个IT的专有名词，从而退化成了一项IT技术工具。这说明过度注重IT技术的结果，将会使BI距离业务越来越远。
一份调查证实了当前国外在商业智能上高度注重业务的倾向。今年Gartner研究公司的副总裁和著名的分析师Burton在调查了350家企业的商务智能项目后说，商务智能(没有成功)的核心问题不是技术问题。问题则恰恰是商务领导人方面的失败，他们没有能够确保企业得到他们所需要的信息，并且没有把信息按照对企业目标有意义的方式进行调整。显然，这实际要求BI的信息要按照业务逻辑进行组织。调查中列举了Coldwater Creek Inc.公司。它是一家专门供给职业妇女的服装目录编制商和零售商，该公司成功运用了BI。公司创始人Dennis Pence说，(商务智能)绝对不能是一个IT项目，
“
我不认为它在脱离了商业的情况下会有什么意义。商务应该感觉他们在某种程度拥有它。
上半年的CHICAGO
——
Gartner商业智能峰会重新定义商业智能。峰会上主要发言人认为BI要从商业策略、商业策略、人员和流程、分析应用四个方面介绍了如何帮助业务的成功。可参见本人博客《BI，中国人可以对你说不-----评2007 Gartner商业智能峰会重定》。
可见，以业务驱动为方向应是BI的趋势。但是上面描述的问题却恰恰说明当前BI往往是以数据驱动为方向。原因一是，发起者的角色错位或角色责任转化的不易实现。BI的发起者往往是信息中心等技术部门，而不是业务部门发起或业务部门联合信息部门发起。二，BI泊来品照搬国外未经消化的后遗症。BI引入国内，即是以报表，OLAP的旋转、切片等概念和演示呈现给用户，把用户带入了技术的胡同。三，业务类人员包括不少企业的一把手，对管理精细、数据分析、强化经营效果的意识不强，不易打动业务人员的参与。四，非技术的业务类人员对BI技术的使用并不熟练，兼之BI界面方便性有待提高，导致业务类人员往往认为BI是增加了自己的工作负担。
上述原因，往往在BI实施前后过程中形成了技术部门占主导的局面。这直接造就了BI以数据逻辑进行组织，并且直接构成了数据标准、数据源获取、数据组织和存储、数据利用和展示的BI主要环节。并由此形成了元数据管理工具、主数据管理工具、数据集成与交换工具、数据仓库工具和前端展示工具这些产品。此时此刻，BI往往被定义在了前端展现工具上，即BI成了数据生命周期中的一个最终环节。集成商的开发人员考虑业务最多的是在这个BI展现环节，也就是特意强调这个环节满足业务的需求。显然，这造就了BI的恶果，埋下了BI不易达到实施目标的祸根。首先，由技术部门牵头必然容易滑向自己熟悉的领域，特别是数据获取、数据组织和存储这些过程；其次由于涉及部门较多而业务类人员并不用心参与，造就了协调的难度；再次，面子意识以及官本位容易使信息负责人希望实施人员要拿出成果且能拿得出手时，才愿意组织业务类人员郑重洽谈。此时往往技术开发人员被要求要做出一个完整的DEMO出来。当考虑很少业务需求的DEMO做出后，信息部门觉得界面不好看、色彩不鲜明等原因担心引起业务类角色的笑话，又以自己的想法强迫技术人员重新修改。可想时间花去了，解决业务问题的要求却远了。鉴于上述，即使项目经理或技术开发人员抛弃了自己的技术思维跨入业务类思维而考虑到了在数据生命周期各环节要以业务需求作红绳，以贯串整个数据过程也难以在工作中真正做得到与此想法相匹配的行动。更何况，信息部门、技术人员中的多数根本不具备业务管理方面的思维和管理知识素养，以及对业务的深入了解能力。
可惜！可叹！
总结之，技术占主导局面非常容易使BI跌入数据驱动陷阱。数据驱动有什么不好？数据驱动模式很好，它由数据的深度挖掘来辅助业务，它将企业所有的数据都整合、清洗并按不同的粒度存储起来，业务类人员用什么数据都能提供。技术部门也似乎能一劳永逸。但是，该模型可能不适合当前国内BI发展的现状。原因除上述所言，数据导向容易把BI的根本在于商务，应由业务逻辑来组织数据的红绳莫须有化，结果使得BI偏离业务偏离企业的绩效日益远之；另外，还有以下原因。如人员素质以及用户习惯。用得上BI的企业信息化程度应该不低，但是能用各种方法和工具从数据中提取有效信息的业务人员并不好找；又如变化。用得上BI的企业业务应有一定稳定性。然而花大力气整顿好的数据，却可能在竞争环境下对战略战术的调整而致使数据毫无用处。再说财力和成本，尽管能上线BI的企业财力不弱，但如从数据驱动出发长期整理数据，成本之高确实难以承载；笔者曾从事一个BI项目，仅是把数据搞准确就花了两年,而事实上搞准的那些数据能用到业务类人员所关心的管理问题方面的非常少，价值很低。最后从项目成果来看，数据导向耗费大量时间在数据的一致性等方面，在业务需求和业务逻辑的理解和深入上尽力不够，结果匆匆忙忙拿出的成果是报表和一些DashBoard。由于涉及业务肤浅，本质效果很少，就花时间在界面的美观和绚丽上，敷衍领导。
数据驱动的技术主导方向，在8月份Business Objects公司在杭州凯悦酒店所请嘉宾的职业亦可见一斑。据主持人介绍，听众由政府行政人员、企业人员构成。在进一步的讲师讲课互动中得知绝大多数人员担任信息中心工作，即技术人员占绝对多数。当鲁博士提示是否有业务人员时，现场无人举手。可见业务类人员的参与度极低。
数据驱动的技术主导，业务类人员参与度低，这显然是企业最高领导的责任。正如Gartner研究公司的副总裁和著名的分析师Burton所说，当商务智能软件项目失败的时候，IT通常是受到责备的那个。但是这个失败却通常会追踪到领导能力的缺乏，而不是技术。但是谁又敢去责备一把手？谁又能去责备一把手？不仅是因为它的公司地位，更重要是他没有他正确理解的BI体系和BI概念以及正确的BI方向。
即意识层面的体系不清和方向不明，导致了一把手的错误决策，同时也导致了业务类人员的低度参与热情，最终导致了BI结果的不如人意。这难道是某一个人的错误？
罪三：数据不准 ，相关者爱恨交织，BI让人不能心安
实施BI，最容易出现的问题即是数据不准。看着BI生成的报表，业务方面的经理们很容易说，
“
嘿，数据是错的
”
，从此对BI数据的使用怀有阴影。或者他们会指出BI系统和其它操作型系统对同一个指标的数值不一致，我究竟敢用哪一个数据？主管技术的信息部门面对此种指责与怀疑更是羞愧不安。好不容易抽取完数据，花子大量时间验证数据的一致性，又花大力气构建了数据仓库，本以为前端对数据展示就可以收工了，殊不知竟然基于数据在界面上被别人逮个正着，又得回到数据检查错误来源了。真是又爱又恨
确实，数据质量控制对于BI成功非常关键。据《商业周刊》去年的研究显示，43%的商业人士不能确信他们企业内部的信息是否准确，77%的被访者表示他们因为缺乏可信的信息而做出过失败的决策。这其中，数据的质量存在很大的问题。举例来说银行数据库中的信息少则几千万条，多则几亿条。如此庞大的数据量质量却不一定好。同名账户、废弃账户，一个人有多个账户，这些信息需要专业的工具来清洗和改良。对于数据输入时质量控制更是得及早预防和改善。
笔者从事的BI项目中，同名不同义，同义不同名的字段名称的一致化就耗时甚长。对于那种字段类型不一致的也是非常之多。有时一个指标的数据发生错误，但是却要花费不少精力来查出错误的源头。在某个数据进入ODS区域，再进入数据仓库，数据集市后，技术人员往往不知道该数据是如何被利用以及数据的利用路径。实施现场的技术人员尚且如此，更何况做维护的工程师了。
异构系统通常是原始数据脏的原因。从原始数据整合起，数据的抽取、转换、清洗和加载过程属于技术过程。一般来说ETL工具保证了某些部分的数据质量，例如剔除那些有空白字段的信息、找出小数点明显点错的数据等，但是目前的数据集成与转换工具大多集中在数据的抽取、转换和加载方面的功能，对数据质量保证不够重视。这是因为相关确保数据质量的工具比较缺少，因此在目前的大多数BI项目中缺少从技术角度去确保数据质量这个环节。
数据质量控制是BI实施中极其困难的一个环节。对原有异构数据一致化的困难过程，对源头上新数据的质量控制的新制度约束艰难，都是当前BI难以成功完成目标的重要障碍，也成为大多数复杂BI项目最容易受人责难的焦点之一。
除了开发人员的经验和细心尽责之外，高效能的数据质量工具是解决上述问题的重点。
罪四：应用不实，成为作
“
Show
”
，BI难以解决实际问题
“
应用不实
”
或许最能激起BI从事者的共鸣。
当信息中心有关人员要求开发实施者不停地在大量的报表中折腾时，他们有没有想到这些宝贵的时间是不是要用在研究企业的业务逻辑方面。当我们的信息主管在责骂实施组需求研究不深入时，他们有没有想到项目实施组所谓的业务专家想充分了解业务却又在企业信息主管因担心弄不好遭同事笑话的阻隔下而不能深入了解业务运营时情景。
当业务人员指责已经做成的BI系统只是一堆垃圾，或者说大部分功能不实用只是
“
Show
”
而不能提出有价值的信息时，他们有没有、会不会好好反省一下：
‘
我已经让企业、让技术部门、让实施人员清晰地了解了我们想要从商务智能中获得什么了吗?我是不是已经用关键业绩指标来将业务运作的核心点联系起来了么？业务人员指出数字并且说，这些数字是错误的，要将他们改正过来。把它们改正是比较容易，花费些精力和时间总是能够完成。
如果没有与业务运作的逻辑紧密联系，就算将数据搞得多么的正确，就算将报表和DashBoard做得多么的绚烂和形状怪异，亦不能让BI帮助企业实现管理上的节流和营销上的开源，因此BI亦势必不能发挥更大的作用。
这就是应用不实！
应用不实，是当前大多数BI项目的通病，也是阻碍BI发展的核心问题。应用不实表明，BI这种分析型的系统不能像操作型的流程型系统一样真正贯入企业的业务流程，不能帮助业务人员解决问题。也就是说BI不能落实在工作之中，它成了一种
“
Show
”
。
“
成也萧何，败也萧何
”
，基本不需要改动流程这种BI系统的特性，既成了BI实施启动的优势，也是BI实施不能成功的劣势。
应用不实的原因涉及到多个方面，业务和技术的协同问题，业务类人员对BI的理解以用业务类人员自身素质问题，业务需求的多变因素等等。
罪五：全程不通，衔接处参差不齐，无形中加大BI集成商开发和用户维护的难度
集成商对
“
全程不通
”
应该最有感触。集成商在面对客户时抱怨做BI系统要综合个厂家的BI产品，难以权衡，同时又在暗地里得意：没有这么多的厂家，我的价值从何体现？全程不通，造就了集成商开发BI的难度，也约束了最终使用单位不一定属于专业的技术人员对BI的自我运用。当然，也造就了集成商对
“
BI产品选型
”
的独特优势，也使最终用户难以把握住产品选型。
BI系统可以简单地看成由三个部分组成: 数据源到数据仓库（或数据集市），再到前端展现。三部分间相关的软件产品和工具有很多种，而每个工具之间的连接都存在相当的二次开发工作。没有全程连通的产品，或者说没有哪个厂家真正具有全程联通的产品，造就了当前的困境。下表列出部分当前的BI产品。这些工具支撑了数据标准、数据集成与交换、数据存储和数据应用以及元数据管理的BI主要过程。
上表列出的BI产品是各厂家的强项所在。近来，上表中的部分厂家开始了向上和向下一体化的步伐。以数据库为拳头产品的厂家通过收购或自我开发的方式，向下进一步挖掘与开发元数据管理产品、主数据管理产品，向上开始注重前端展示类产品、把报表与展示类的产品收归麾下。如以DB2为基石的IBM即收购了alphablox作为BI数据利用的前端展示；在前端展示市场占有率极高的BO，现在开始提倡BO的数据质量、数据管理和数据利用为一体。主数据管理是其强调的优势。又如做统计分析很牛的SAS，其分析、统计预测的能力，行业内首屈一指。SAS现在宣称其拥有从数据源到数据仓库再到数据利用的全线产品。
从尊重历史的角度实事求是地讲，各厂家由于有某项强项产品，才得以在竞争中生存。不可否认在较短的时间内一定有能力开发出其上下游的产品，但是市场能否相信该产品的成熟度，市场能否接受呢？如果是收购或兼并，必然或多或少也要涉及软件之间的整合问题。确实不易。
罪六：工具不全，手工操作之处不少，既降低开发效率又影响应用效果
全程不通，讲的是BI现有的全程产品主要由拼凑而得，总体上还缺乏一套成熟的全程产品。工具不全，描述各个环节产品还存有工具不全的罪状，特别是在数据层面和应用层面。
在数据层面，当前的元数据管理工具似乎并不能面面俱到。元数据管理，管理着技术元数据、业务元数据。技术元数据，主要包括对数据仓库的数据源数据、目标数据的描述以及它们间的抽取、转换、清洗规则，以及数据仓库的维护和数据更新策略。业务元数据向业务用户提供了访问数据仓库或数据集市的导航数据，通过业务元数据，业务用户可以清晰地理解数据的含义及相关的处理（基于统一的业务术语），因此业务人员可用此来作其操作的导航，以保持分析结果的一致性。举技术元数据的例子，当前的工具难以监测到某个数据的生命周期或者说利用过程。比如，技术员得知业务人员发现报表中某个数据出错后，需要花费比较长的时间来寻找该数据的来龙去脉。如果有强撼的元数据管理工具还需要如此费力么？
在应用层面，也就是BI的数据利用层面，现有的工具在帮助客户解决问题方面仍有不足。笔者认为支撑应用的BI工具有7类：描述性统计工具、报表与展示工具、经济预测方法与模型、经营技术与工具、OLAP分析及专家系统工具、决策方法与模型来实现。7类工具各自又含有自己的类别工具。另一方面，当前的应用支撑工具还不能将工具与应用串起业，也未能将工具和应用与别的工具和应用，按业务逻辑的方式串起来。因此，在应用层面，当前的BI工具还有待发展。
当前大型企业在实施BI后，通常建立了专们的BI分析团队。据报道，神州数码的所有员工都已不同程度地成为
“
初级BI分析师
”
。宝钢实施了SAS的BI后，在企业内部有100名左右的专职分析师。试想，如此庞大的队伍，如果不能利用完善的工具，其成功率、效率与成本值得考察。实际上，并不是所有企业都能培养专职的分析师队伍，普通员工操作着部分且不一定能有效的工具，如OLAP分析工具，花了大量的时间并不能解决其设计的问题，岂不是怨言满天而阻碍了BI的进一步发展？
六宗罪源于当前BI的先天缺陷和后天不足
BI六宗罪源于BI环节的肥瘦不均、先天缺陷和后天不足难以保证结果而又期望过高，导致差距过大。如下图所示。
首先，理念层在体系和BI方向上的认知不一致，容易被误导或者出现混乱，从而在项目洽谈前就埋下了先天缺陷。
这种缺陷客观存在，基于BI的发展历程或者说大家对BI认识也渐进过程。先行者为此缺陷埋单位！或者说不自觉地为完善对BI的认识付出了昂贵的成本和精力。理念层面环节是当前BI最为虚胖的环节，隐性地制约了BI的真正发展。
其次，基础层面不牢靠，支撑不力也是项目洽谈前的先天缺陷。
合理选型有意识地规避了部分基础层的风险，它通过一定的提前措施尽量减少了不足。但是从整体来看，仍然是在缺陷中减少缺陷的方法，只能是在缺陷中将风险压制到最小或可以接受的程度。该环节也是BI比较虚胖之处。
由于甲乙双方在项目认知的冲突，或者甲乙双方一致但双方与BI正确方向和体系的冲突，并且由于工具方面的缺陷，特别容易导致项目实施时的后天不足。因此执行层在面对异构数据时，由于工具和数据质量等客观原因及其它主观因素，导致数据不准；而双方对项目认知的不妥，致使项目难以协调，而导致最终开发结果华而不实，没有实际价值。可见，由于BI先天的虚胖，加之于后天的困难则更多，导致BI实施失败的可能大大增加。
从实施BI的角度，在当前并非落实BI最佳时刻的客观环境下，BI厂商、用户和集成商应该清醒地统一认知，谨慎地规划与工具相匹配的应用。酌情而作，应是上策。
从BI发展的角度来看，BI应该在理念层、执行层和基础层协调配合，以理念层为指引，引导基础层和执行层。
-The End-