zoukankan      html  css  js  c++  java
  • 我看BI在中国(转)

    我看BI在中国

      本文是一位资深从业者对BI在中国的看法……
     

      2002年,当时我正在一家报表公司工作,为中国大江南北的客户做报表和数据分析。一个偶然的机会,我接触到了BI,准确的讲应该是OLAP(来自SQL Server 2000),我被OLAP强大的分析功能所折服,那种随心所欲的拖拽,快速的钻取将我当时所做的报表分析打击的一无是处。我看到了我的方向,也看到了中国数据分析的方向,从此我便与BI有了不解之缘。

      准确的讲,很长一段时间我使用的都是OLAP,现在总结起来,BI不仅仅包括OLAP,还包括报表数据挖掘,不同的部分提供不同的功能。

      在我接触到OLAP之后,我就认定了一件事情:OLAP会取代报表。我甚至怀疑SQL Server Reporting Services存在的意义。

      我也的确这样做了,不久以后,我就进入了一家专业从事微软BI解决方案的公司。我开始向我的客户推荐OLAP(即SQL Server Analysis Services + ProClarity),我希望用OLAP来解决他们目前所有的报表问题并提供更加丰富的数据分析的方式方法。

      客户看到我的演示,他们是惊讶的,就像我当年第一次见到OLAP的时候,他们没有想到数据分析会变成这样,会如此的灵活和随意。看到他们的惊讶,我知道他们和我一样,喜欢上了OLAP,我想要的效果达到了。

      接下来顺理成章的就是进行项目实施了,我先说出项目实施的结果:失败了。

      为什么?我也无数次的这样问自己。

      不过,现在回头来看当时的项目,失败是必然的。当客户看到OLAP的时候,他们非常欣赏这样的分析方法。然而在我们进行项目实施的时候却发现,这种新的方法只是客户工作中的附加品,我们最重要的是完成他们现在所有的报表工作。

      于是我们就开始在OLAP系统中去做客户已经制定好的报表,但我们却发现,客户的报表总会或多或少的有一些不规则的地方,例如突然在表格中多出了一个小计,或者有这样或那样的特殊的表格线。而这些不规则的地方在OLAP系统中几乎都无法实现,因为为了实现钻取,OLAP的表格必须是规则的。

      矛盾就这样产生了

      我们无法理解客户为什么一定要求那些特殊的表格线而不看重那些优秀的分析功能,客户则无法理解为什么我们的软件连几条表格线都加不上去,因为这些表格线对他们来讲太平常不过了,他们以前都是在Excel表中把它们画出来的。

      同时,我们也用OLAP系统做出了客户的一部分报表,但我们却发现,在实际使用过程中,客户从来没有在我们的OLAP报表上进行过钻取,而只是把它当作一个简单的报表来看。也就是说OLAP的优势客户从来没有使用过,而弊端却完成体现出来了。

      最后,因为我们的软件无法满足客户的全部需求,项目失败了。我也迷茫了。

      失败势必引发思考

      OLAP真的是报表的替代品吗?我重新开始思考这个问题,也开始真正接触Reporting Services,我惊奇的发现,客户那些非常规的需求在Reporting Services中奇迹般的都被解决了。至此,我终于明白:OLAP并不是报表的替代品,OLAP与报表需要相辅相成,来解决客户不同的需求。

      客户真的需要OLAP吗?OLAP在国外已经很多年了,已不是什么新鲜事物了。为什么在国内使用起来却如此艰难。这不由的让我想起了余世维讲过的一段话:“中国在硬件方面用10年的时间追上了和美国落后50年的距离,而软件方面我们依旧落后美国40年”。这里的“硬件”是指所有可以用金钱买到的东西(包括我们平时所指的软件),而“软件”则是指人的思想。当SQL Server 2005发布之后,我们就可以使用了,因为我们可以从微软买到这个产品,然而我们客户的思想和美国人的思想一样吗?他们的思想能够接受这样的产品吗?这需要我们去思考。

      有了前面的失败,我们调整了思路,开始设计符合中国特色的BI解决方案。我们的项目也开始成功。

      接下来,我来介绍一下我们具有中国特色的BI解决方案的几个特征:

      1. ETL

      ETL是以前我们所不太在意的部分,然而,实际当中,ETL已占用了我们70%的工作量。国内客户的源数据各式各样,甚至会有很多Excel文档和纸质的报表,这些源数据并没有严格的业务规则来限制它们,所以数据的准确性存在很大的隐患。并且很多隐患是客户也不了解的,往往只有在最后报表中才能发现数据存在问题。这些问题只能通过调整ETL来解决。ETL的调整是往复的,一般都要经过几十次的变动,而每一次对错误数据的追根求源却变得极其困难。所以,我们将花大量的时间来建立严格的源数据的业务规则。

      2. 动态报表

      前面讲到,客户对OLAP很感兴趣,但在实际的工作中却极少使用它,那么,客户究竟需要的是什么?传统的报表客户基本已经实现了,我认为,他们需要一套新型的报表系统,这种报表系统将介于OLAP与传统报表之间,兼顾两者的优势,即可以实现传统报表的格式要求,也会有OLAP的一部分的灵活性,这就是动态报表。

      目前Reporting Services正可以完成这种报表,我们还通过二次开发,给Reporting Services增加了更多的可操作功能,使客户在同一张报表内可以看到更多的信息。

      我们在前端展示方面,90%以上的工作是制作报表,而OLAP功能只占了很少的份额。我们还是希望将这种功能推荐给我们的客户,一方面这样更容易拿下项目,另外一方面,我们也希望通过OLAP产品来推动客户思维的提升,我们相信,不久的将来客户一定会接受这种全新的分析方式。

      3. 漂亮的外观

      曾经我不认为漂亮的外观是重要的,因为我觉得在数据分析中数据是最重要的,然而我的客户并不这样认为。在实际的项目中,漂亮的外观变得尤为重要,所以我们经常要引用一些第三方的控件,来增强整个系统的美观性。

      现在可以毫不犹豫的说,漂亮的外观已经变成我们拿下客户的一个杀手锏。

      4. B/S与C/S相结合

      目前所有的系统都流行使用B/S架构,而我们却在系统中将B/S与C/S相结合,客户中的大部分使用者会使用B/S架构,而关键的决策者(一般是领导)却使用C/S架构,因为C/S可以提供更强大的功能,更多的向导,更漂亮的外观,甚至是更傻瓜,但这正是领导所喜欢的。

      现在我们所有的项目都很顺利,回过头来看,BI在中国的应用尚浅,前面的路还很长。但我相信BI的方向是正确的,我们需要等待客户思想的提升,这对我们来说也是一个机会。

    SpagoBI中文社区,致力于国际优秀开源BI套件SpagoBI在中国的普通推广; 联系我们QQ群:275725345
  • 相关阅读:
    阅读prettytable 一些代码、get、set 检查参数
    python 库 PrettyTabble 使用与错误
    python 内建模块与第三方模块
    python 排序 堆排序
    python 排序 桶排序
    python 排序冒泡排序与双向冒泡排序
    python 函数式编程 闭包,返回一个函数
    python 排序 选择排序
    python 排序 归并排序
    python 排序 插入排序与希尔排序
  • 原文地址:https://www.cnblogs.com/mybi/p/1799182.html
Copyright © 2011-2022 走看看