ITPub博客

我很喜欢用"忽悠"这个词，有些自嘲，因为我们经常要说一些没有谱，却装作很有谱的事情。其实这点恐怕连客户都知道，很多时候，他们其实很需要这种看起来很有谱的事情来装门面。 但除了看起来有谱，这些忽悠后面必须得有一些有价值的东西。可惜，当这个词用多了，很多人认为编瞎话是你的职责，就连自己项目组的人都是这样认为。认为跟客户打交道的人，就是应该花言巧语去蒙骗他们。因此，似乎交付件的好坏就不重要，一切都有这些忽悠子来包装。 被这样看待是一种悲哀，其实如果有好东西，为什么还要忽悠客户呢，客户不是傻子，能

讲个BI笑话给诸位听听，轻松一下。 阿Q在BI领域混了80年，在80岁那天，他的人生之路走向尽头，弥留之际，叫来几个朋友，老友老G和小S，还有一个晚辈小Z。 阿Q"哦，哦"两声，三人都围到床边，问有什么遗言要发表。阿Q费了好大劲儿，模模糊糊蹦出几个字，"莎～士～比～亚～"。 小Z赶紧去书架上找，一会儿回来，手里拿了一本《哈姆雷特》。 说："老Q，你看，这是莎翁名著，我会把它给你陪葬的，安息吧！" 阿Q"呃～"的一声凄惨，看来不是。于是小S去书架上找，看到一本毛选，里面有些毛片，取出一张塞

最近给公司写"Advance Dimensional Model Solution"的PPT文档(英文)中, 目标就是帮助在一般项目中如何快速建更好地建模型去服务业务模型以及更多BI应用, 不仅仅是OLAP应用。这里主要讲维度模型，不涉及如何构建整个数据仓库系统，就是谈数据集市这个层面如何更好地为业务需求服务。 主要谈到以下几点: 1. 用DW2.0的某些优点来帮助更好地建设多个数据集市的MD构建思路. 从一个新的角度看待问题，比如数据联通性等等。 ----- 以数据仓库整体架构思路考虑, 适合多个数据集市, 多个部门的多业务分析BI需求. 2. 数据集市和数据模型,

谈"OLAP工具毁了BI",本身没有涉及到DW. 最后居然和 innovate511 在DW与BI上一直争论起来.正常争论而已,innovate511先生不必太郁闷. 其实我们讨论BI的目的是为了更好的实现BI,但如果各位认为我有推销之嫌疑,我尽量不提产品. 我认为,如果市场对BI效果失去信任的话,DW也将受到极大影响. 但有一点,我必须认同innovate511先生的观点, 目前的BI厂商试图利用元数据管理解决方案来解决数据质量和集成问题，这是一个非常错误的提案.因为数据上架、清洗等工作不是BI的范畴，的确是DW的地盘。 其实和innovate511先生讨论到最后变成"DW

经过繁忙的一天工作，阿Q跑到西北杂粮馆吃面，点了一碗岐山臊子面。 一番希里哗啦之后，阿Q的郁闷情结起来，猛地站了起来，大力一掌拍在桌子上，玻璃随即碎成18块。他大唱到： 老子今年二十七至今没有召过鸡天增岁月人增寿不能再负小弟弟 这时候，旁边一哥们，西装革履，正对着笔记本边吃饭边上网呢。听到这一顿唱，边走过来，递上名片，上书"神马公司BI资深权威高级顾问牛BI先生"。下面是两人对话。 牛：听到先生如此苦闷，鄙人不才，有全套BI解决方案帮您消除烦恼。我们代理全球各种BI工具，并且可以为您的喜好度身定做。请问

周末在图书馆蹓跶，瞅见一本书——《三位一体的商务智能》，这本书在一些国内BI社区里面有所宣传。作者王茁，还有一位作者叫顾洁，看介绍，怀疑是他媳妇儿，难道是珠联合璧？在印象里面，难得有中国字原创的BI书籍，便借阅一读。 所谓三位一体，是指管理、业务和技术。在ttnn，经常争论的是业务和技术，上次有位"管理之路"的朋友也将管理提出来着重提出。其实管理这个东西，当然非常重要，不过容易说得很虚，所以大多也没人谈这个。因此，从名称上就能猜到，这是一本全面介绍BI的书籍。而且作者还能找到郁闷先生给作序，也算是镶

1.数据模型永远基于业务模型归纳出来的,不是凭空想象出来的,不是靠看几本国外实践的书就能建的,理论要联系实际,中国的实际要求远比那些国外的书上写的复杂的多. 2,数据质量和数据完整性问题永远不会消失，没有一劳永逸的办法可以解决。别妄想建一个什么EDW能解决数据质量和数据完整性的问题. 数据来源是否准确目前还在解决中. 3,要贴着ORACLE,IBM这些大的BI/DW厂商,参考他们的行业EDW模型去拿项目,项目拿到后,结合用户实际业务的要求,尽量修改项目实施前要求技术参数标准(估计那些技术参数要实现需要化很多代价),尽快结束项目. 4,永远记住

有人喜欢用建筑行业和BI比较,从他对建筑行业流程的描述中来看,他对建筑行业是一点不懂,别以为在上海看了几眼金茂就以为了解金茂大厦是如何建起来的. 本人不从事建筑行业,但本人的亲人却从事建筑行业,父亲从事从事建筑施工50多年,我兄长从事建筑设计近20年(一级建筑注册师),我太太从事建筑结构设计10年(一级结构注册师). 建筑行业是所有行业最规范的行业,远比软件行业规范的多,象软件行业,出一本书,做几个项目就可以自定义牛人,架构师,真是太搞笑了. 看看建筑行业那些一级注册师(就象软件行业那些牛人)的考试吧,首先考的人一定有工作经验,一

在北京开了三天会，一则消息终于确定下来，我们BI这个部门将被废掉。 这不是令人震惊的消息，因为早在四月份就已经有了这个消息，只是尚未明朗而已。领导们很为大家着想，建议大家转做别的，诸如增值业务之类的。为什么砍掉BI部门呢？倒不是领导认为这块没前景，或者说是什么战略的考虑（当然，名义上是战略考虑）。其实大家都明白，是因为价钱没谈拢——这个BI部门主要做的就是外包。跟NCR合作了一年半快两年，项目本身做的不错，大家都挺有成就感，可惜，这根本不是最重要的因素。是没钱可赚？从去年的财务数字看，这个部门是盈利的。当

如果做好项目才是实际的. 我昨天还和公司销售说, 我们销售解决方案的时候, 肯定要跟着客户的思路去推销, 而不能一下把本质问题说出来. 比如客户说某BI产品不行, 报表 不规范, 数据质量差, 报表打印出来很慢. 其实这不是产品问题, 而是实施厂商的问题, BI工具之间没太大的差距, 该有的功能大家都是半斤八 两. 而我们推销实施方案的时候可能绑定一个产品,但不能绑太死, 给自己多一个机会, 只是多突出下在这个产品的成功案例. 数据仓库的建设是数据驱动为好, 还是业务驱动为好, 国外争论了10多年了, 还没下定论, 有同志想下个结论, 那就下吧,

在我看来，Qing现在的状况跟创业一样（"承包一个部门"、"自己去折腾"），都是找投资商支持去搞BI咨询。只不过这里的投资商就是公司老总。所以我觉得可以用创业的角度去讨论。上面几位兄弟，都是老IT了。基本上抱着谨慎不乐观的态度。我想，是不是应了一句老话：越是熟悉某个行业的人，创业的干劲越少。这句话我的理解是，既然是老IT了，目前薪酬也不低，还有家庭负担，所以很难全身心投入去创业。另外，对IT行业越是了解深入，越看出行业内的各种问题、制约、束缚，激情也逐渐被这些负面的东西消磨了。当然了，Qing也

以前，我们有个半月谈会议，跟客户总结一下每个专题应用的进展，有什么亮点之类。后来，慢慢地变成了月经会议，接着变成季候风... 现在似乎是进入更年期，不知什么时候才来一下。上周，终于又坐到一起正儿八经地开会，似乎还是开过年的第一次。这经常不碰，就会发现相互的理解偏差。从过年回来，我们这个项目组一直积极搜集地市公司的分析需求，缩短分析建模周期。这是引以自豪的。可是站在省公司层面，发现这样行不通。 将今年投几个月做的需求呼啦拉拉下来，几十个。领导眉头一皱，根本没有细看。说，这不行，太多了。亮点，亮点在哪儿？

下载了一份OLAP调查（the OLAP Survey 6），这是比较有名的关于BI（OLAP）工具的对比分析，从01年就开始。网站位于www.olapreport.com，这份报告页数不少，好几百页，要付费购买才能看完整版。样板倒是可以免费看，网上有下载的，我也放到这里，大家可以下载瞅瞅： http://groups.google.com/group/ttnn/web/20070215LU9UKRWL--1-OLAPSurve... 这份报告评估的产品包括MOLAP和ROLAP的种种，大致如下： MOLAP有Applix TM1， Congos Analysis，Congos Planning，Essbase，Hyperion Planning，MS Analysis Services，MIK OLAP，MIS，Oracle Ex

前段时间在ITPUB写了一篇"从非技术层面寻找BI成功的关键方法",被IT168刊登了, http://cio.it168.com/t/2007-06-06/2...1511796_3.shtml 发现被压缩了不少.把我的电子原稿放在ITPUB(实在不知道TTNN如何上传文件),愿意和大家进行讨论. 写这篇文章的原因,在于回应"业务模型和数据模型"的争论. 我认为:从技术上来讲,数据模型其实在定义上,功能描述上和性能上也不可能达到平衡,更不用说其对分析所必须的业务模型快速变化的支撑.kimball 的数据模型很多在定义上很美丽,但在实战的性能表现的很差,比如kimball经典的时间维表在

结论，要得是结论。 当看到一份洋洋数十页的ppt，堆砌大量的数字、图形，就有些头大。有没有结论性的东西？没有。即便有，也是淹没其中。按照流行的数据到信息，信息到知识，知识到决策这条路经，这种ppt就是展示信息，却没有发现知识，如果用于决策的话，还差一步，失败。 知识并不容易发现，特别是新的，大家不知道的而令人诧异的知识，经常能够提起听众的兴趣。做每次分析的时候，应该都有一些新知识被发现，哪怕这个知识是一种荒谬的，就怕没有结论。当然，如果抱着"没有功劳也有苦劳"的心态，恐怕就不会在乎是否有结论，抛

今天又看回了CRISP-DM的流程模型介绍文档。 发现非常之详细有用，模型除了大家耳熟能详的6阶段，还提出了分4层的模型，最上面是6阶段，下一层是通用任务（对6个阶段的每个进行任务分解），在下一层是具体任务（通用任务在具体的情况下应该采取什么行动）。比如通用任务是数据清洗，具体任务则有数值数据清洗，或是否判断问题类型是聚类或预测。最下一层是流程实例，即某次挖掘的行动、决定和结果记录。 CRISP-DM还提出了数据挖掘上下文的概念，对于将通用模型映射到具体模型很有用，其由下列某些或全部维度特征组成： 问题域、数据挖掘问题

天降大雨，机房进水，网络中断，好几天没有上网。 古代有个叫匡衡的人，小时候家里穷，没钱买点灯泡。但他喜欢看书，白天打工没时间，可晚上天一黑，就啥都看不见了。他挺郁闷，跟邻居商量，看能不能借个光去他家看书，邻居不愿意。没辙，于是有一天，他偷偷在墙上凿了个洞，从此，他每天晚上就可以看书了。 前几天我也向他学习一把。白天上不了网，着急啊。晚上回家，因为一直没钱办宽带，也上不了网。周末的晚上，还是打开了电脑，就算没有网络，那就听听音乐吧。咦，竟然发现弹出一个skype的自动更新对话框，这可只有连上网才会有的。一

无论是大家在讨论问题的时候, 还是所谓的争论的时候, 都在说IT人员. 但一说到IT人员, 我就想起了大公司的IT支持人员, 而一般也只叫这样的人员才叫IT人员. 一般来说, 大一点的甲方都会有自己的团队, 可能就是所谓的"IT人员". 这些人员中, 可能是专业知识一般的人, 也可能有很强的专业知识, 如果说他们只做数据库管理和开发, 我觉得说的不完整, 一般大公司里他们也会参与项目整体方面的东西, 包括业务分析, 帮助最终用户完成他们想要的分析、挖掘或者一般应用如报表查询. 所以每次说IT人员，不由得想起了支持公司内部IT的人员....

将定性的东西定量，这是现代管理的重要特性。因此，出现了很多"度"来衡量某种特质。比如信用度、忠诚度、满意度、健康度... "度"是数值，是可以比较的，数值越大就越好（或越差），这跟定性的东西相比看起来就客观一点。然而，很多"度"名不副实。比如前段时间谈的信用度问题，有朋友就质疑，你这个信用度真的就能衡量客户的信用好坏吗？仔细想想，不能。其实他只是体现信用的一方面——未来一段时间内欠费的可能性而已。因为没有谁能够给信用一个严谨客观的定义。同样，什么叫做忠诚？什么叫做满意？什么叫

最近工作比较忙，一直在TTNN潜水，看到大家在讨论业务建模和数据建模，我也一直做这个方向，很感兴趣。我把业务建模和数据建模的关系理一下，这样争论也有个基础。当然其中肯定也有不当之处，请多多指点。 先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角等信息用计算机的语言表示出来。这两类建模从方法到目的都是不同的。第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比