ocean

    今天在微软呆了一天，回来后发现昨天写的BI有感有很多回复，同时对我的想法有了很多的建议。今天就再发发感想，不过首先对昨天的一些回复进行一些解释。因为我昨天所想的方案，是考虑以后的可能的一种趋势，而不是你现在马上采用，不成熟的地方肯定很多。

    birdshome和neuhawk首先是担心Office的价格，认为大面积部署Office所需要的成本很高。我们考虑一下，如果不用我们的系统，用户是否会用Office，很明显，大多数人员的机器上都会有Office。也即我们的系统仅仅是利用客户机器上现有的软件，属于保护客户的投资。如果客户原来坚决用WPS，那么我们用Office的这种方案就很BT了。

    ttyp说：“word,execl那么多功能国内人员还只是会用点简单的编辑操作，透视表对大部分人来说太复杂了，能做到更傻瓜么？”。其实在我所说得方案就是做到更傻瓜。比如我在excel的sheet1中抽取数据过来，然后在sheet2-sheet21中做好20中透视表，这些透视表的数据都是来自sheet1的数据，客户只需要看sheet2-sheet21中的已经做好的透视表就可以了，他不需要拖拖拽拽，因为我们已经帮他们做完了。如果客户足够聪明，他就可以自己去定义透视表。实际情况自然是我们开发人员首先制作好，对于我们开发人员来说，透视表这种拖拽的方式就太容易了，比写代码容易的多，同时不同的客户有不同的需求，而且容易更改，当用户需求更改的时候，比如他要调调位置，增加一列，以前我们需要改程序（当然我们也可以在界面上允许调整这些，然后做成动态的，但是客户仍然不会用，而且做这种东西开发量很大）。对于我们的实施人员，只需要给他在excel上改改就成了。

    zz提到：“为什么WORD,EXCEL中国的软件企业作不出来,我感到有些关键技术被封所了吧,同是用C/C++,汇编呢,外国给我的开发工具可能不含这些开发这一功能(如透视表)关键技术吧?? ”，这个绝对不是，透视表只是前端展现技术，属于比较低端的技术，只要你有想法和一定时间，下点功夫都能作出来，做BI的前端展现工具的厂商基本都作的比透视表这种东西好多了。中国软件企业也有做的。

    i.Posei说：“"因为你需要在笔记本上装客户端，而我们的方案呢？不需要，因为你的笔记本上有word就可以了"
word在这里也可以叫做客户端了吧！ ”呵呵，office自然是客户端，但是不需要我们来部署，这个可以认为和操作系统一样，都是客户已经预装好的。我所指的客户端是我们采用c/s方式开发的项目中单独开发的客户端。

    Ninputer说客户基本只用到word中10％的功能。不错，很多东西客户不会用。但是我们做出的方案中可以借助很多Word的特性。比如我们做的Office方案，有笔迹留痕和版本记录（这是Office的功能），当给客户讲笔迹留痕、版本记录等功能的时候，客户认为这是很好的功能，而客户自己都搞不清楚这些功能本身就是Word的还是我们自己开发的，他只认为这是我们方案所能实现的，这样可以用很少的投资得到丰厚的回报，想想如果我们自己在B/S上做，如何做笔迹留痕呢，即使做出来是不是花了很大的代价？而我们仅仅是教会了用户如何使用笔迹留痕功能。

    redmoon说道：“我们这样开发系统，用户看到都是Office，我们拿什么来卖钱呢。”，太经典了。但是我们应该遇见到客户消费习惯的变化和理性。我说的方案可能是以后的一个方案模型，并不意味着现在就能够成功。当客户越来越理性之后，他会更注重你给他带来什么，你给他带来的是不是他想要的，而不在乎你是用Java、.Net、Office还是什么其它的技术。不会像现在一些客户在开发系统之前先说要用B/S做、C/S做还是SmartClient做，这种不说需求先说技术本身是种不理性的表现。以后我就拿一堆Office文档去卖，哈哈。消费习惯是慢慢改变的，我们现在的实施费和软件费基本是1：1的了，也即客户出的更多的是服务费而不是买一张光盘回去。

    montaque说：“你了解不多，国内大大小小的BI ISV 挺多的。 简单讲，目前所谓的BI主要特性就是reporting，可以让业务用户很容易定制自己的report。后台采用molap，rolap还是简单的db，用户才不care呢。 ”，你所说的是Reporting，而我说的是BI，完全不同。BI的主要特性绝对不是Reporting，Reporting只是BI的前端展现，是BI最末端的东西。BI是从OLTP->DW->OLAP->展现（比如Reporting），当然国内和国外很多都是做Reporting，因为这是技术上最简单的。我们国内大大小小做Reporting的ISV多，但是仅仅是Reporting，而不是BI，因为这些Reporting基本都是OLTP->Reporting上的。这只是我们普通说的报表而已，而不是BI。所以说国内做Reporting的多，但是做BI的很少。而且做BI的也是做BI的展现层（很少几家）。

    小诈提到了Word二次开发不稳定的问题。呵呵，这个我解释一下，我们最近的一个系统也是用Word来作为主要界面，在二次开发上确实存在很多问题。不稳定绝对是一个大问题。我们公司有强大的微软技术支持，所以最终把所有不稳定因素都搞定了。如果你没有一定的技术积累和微软专业技术支持，千万不要冒险来做Office开发方案，你会死的很惨。我们在这中间也有很多惨痛的教训，现在想想还心有余悸。当然很多东西要向前看，我所说的方案是我所想的一种趋势。

    birdshome还提到了一个致命的问题，就是客户Office版本的问题，比如Office97/2000/xp/2003等。这绝对是一个大问题，可以说是无法解决的问题。2000/2003还好，其com模型虽然有差别，但不是很大，可以根据版本做不同处理，但是97就麻烦了。我们怎么解决呢？只能劝客户升级。97和2000的文档是不兼容的，想想一个供应商发给我的word2000文档在我公司里面竟然不能用word97打开，是不是我需要升级呢？升级当然升2003，因为升级费用差别不太大。所以在实施方案之前应该对客户的环境有所考察。同时我们考虑两年以后的情况会怎么样？

    Rover提到：“旧东西新概念，这跟vba调用com还不是一个样，wps同样可以给你个接口让你实现，至于通讯方面开发商同样可以提供组件给你使用。至于智能文档，他能在非微软office的软件中使用吗？ ”。呵呵，我觉得这是最没有道理的回复了，你连com都可以不用，用汇编自己写一个操作系统出来，完全都可以实现。但是我所说的是里面的成本。你自己写当然没有问题，但是成本高昂。WPS同样可以提供一个接口，这个没错，但是可惜金山公司不能获得最新的微软技术，特别是未推出版本的技术，所以即使推出接口也是滞后的事情。并且因为没有核心代码，所以不能紧密集成。退一万步说如果wps和sps集成了，那么wps就彻底被打败了，因为sps是Office内的一个产品，你把你的一个office产品集成到了别人的Office产品中，那岂不是一种悲哀吗？如果金山也自己写一个SPS，呵呵，估计金山没有这个实力。很多东西不是写不出来，而是你没有人力和财力支持。后面的一个评论我会更详细的解释。

    Rover紧接着提到：“引用“当用户在excel中输入一条数据时，可以轻易的刷新回服务器” bs系统中难道不能用脚本调用com组件访问数据库，现在是微软已经替你做好了，js+xmlhttp不是照样无刷新，说offfice是智能客户端,可IE就更是智能客户端了，http协议本事是断开连接的，我同样可以在IE中打开一个网页，使用脚本+com组件访问本地数据，需要更新时也调用com更新远程数据。如果这些负责通信的com都由微软实现了呢，那我们客户端只需要一个IE ”

    一种需求可以用多方方案实现，而你偏偏选用汇编来实现。我做js的水平我想大家也都知道，用js+xmlhttp自然可以实现，在B/S种调用自己开发的Com也可以实现。但是我所告诉你的方法，不需要你写任何一句代码，不需要付员工多少天的工资，只需要几分钟就可以做出来，你乐意花费人力物力自己写，当然我也没有意见。现实情况是微软不会把你说的那些com实现，相反它把这些功能都实现在Office中了。

    当然这只是我对Office方案的一些想法，很多地方都是不可行的，实际上对我个人而言我很希望做出一个这样的系统，这个系统的前端都是Office文档。虽然我们现在也基于Office方案，但没有做到这么彻底。这种方案也有很多问题，最大的问题就是版本更新。比如我在某个文档中多加了一个功能，在一个仓库管理.xsl中增加了一张报表，那么我就需要把这份文档重新拷贝给原来拥有这份文档的人。更糟的是原来那些人对他们的excel做了个性化处理，比如A在里面加了1报表，B在里面加了2报表，这样A和B的文档就不一致了，当版本更新后，他们原来自己定义的报表就没了，这该怎么办呢？这实际上是个很头疼的问题，在开始就必须有一个自动更新的机制，能够解决这当中碰到的各种情况。并且还需要不同的版本能够共存（当然这个比较简单，只要不更改原来的参数，而是多放出来一个新版本的ws就可以了）。等等，问题可能还有一大堆。

    说了一大堆废话，还是说说BI吧，BI通常用于客户范围很广的企业，比如电信、银行、证券、保险、超市等，因为他们需要通过BI来把握用户的习惯，从而进行决策支持。网友montaque将一些概念搞混了，认为reporting就是BI，其实BI很大一部分是mining（挖掘），也即数据挖掘，什么意思呢？建立一堆模型，对原先的数据进行分析，然后对这些模型进行填充，同时修正这些模型。有什么用呢，当有一条新数据过来时，可以判断这个新数据属于哪个模型，然后得到这条新数据应该具有哪些属性。比如一个35岁的中年男人和一个35岁的中年的女人，他们去买车险，同样的车、同样的车龄，很有可能就因为性别不同而保险金额不同。挖掘可能根据以往的数据建立的模型，将男的35岁的放入一个高危人群的模型中，这类人事故发生率高，保费就相应高；而把女的35岁的放入一个相对安全的人群的模型中，这时保费也相对低。这是BI的深层次的意义。

    如果仅对现有数据进行展现，比如这个月销售了多少，赔付了多少等，这是报表，也即Reporting。这还不能称之为BI。

    刚刚我在上面解答网友问题的时候提到一个“OLTP->DW->OLAP->展现”的这么一个过程。OLTP指的在线事务处理系统，也即我们通常说的业务系统。DW是Data Warehourse（数据仓库），OLAP是在线分析处理系统，最后就是一个展现，展现就是通过各种华丽的界面将数据表现出来。在sql server2005中，对分析和挖掘都有了更加强劲的升级。

    一般的企业是用不到BI的，特别是很多生产型企业，通常通过有限的一级代理商来卖东西，所以没有和众多直接消费者打交道，这样就需要一个OLTP，然后需要一个reporting来看我的业绩就可以了。比如看看这个月比上个月增长了多少（reporting能看出这个结果，增长了多少，而BI能告诉决策者为什么有这个增长，这是显著的一点不同）。这种OLTP->reporting的系统对绝大多数企业都足够了，不需要BI，BI方案确实很贵，也不适合中小型企业。我对BI的一些东西感兴趣，但不是说我要去做BI方案，所以像网友提到的组建BI团队，我没有什么兴趣，而且我也觉得实在没有必要去组建一个BI团队。

    今天不讲了，呵呵，一些胡思乱想而已。

    欢迎访问海洋工作室（http://sps.oceanstudio.net）