对业务的理解体现在BI工具的使用还是在后台建模?

innovate 20061106

上次提到的关于一个同事说以前他所在前公司和其他公司合作一个项目,
面对客户越来越复杂的报表需求, 后台模型支持不足,
只能仰仗BI工具的所有功能去实现,
然而很多情况下还是不能实现.

象这种后台和前端BI由两公司合作的情况越来越多,
客户提出的合理BI需求可能会导致做后台的公司把更多实现业务逻辑的技术责任全推到前端去.
于是我在想, 这样做后台, 他们到底对业务理解了多少,
到底对DW与BI的关系理解了多少?
如果我在当时那种情况,
可能我会跟客户豪不客气地指出那是后台问题,
不能都依赖于BI, 如果合作公司不知道如何建模,
我可以提些建议或者自己加一层模型作为展现使用.

如果说所谓的架构太空虚, 挖掘算法应用实在拿不准,
但我想比较成熟的模型设计还是有足够空间给各个公司和DWer去研究和探讨的吧.
不过还有一点, 很多公司其实有高手, 但在具体操作上,
在一些普通项目上, 可能会启用相对新的人去做,
而在公司技术积累上, 新人也没去继承,
我想这属于管理层次的问题了.

li-zhenguo 20061106

就像移动会找多个公司帮他架网铺线设基站一样，其他较大型公司也不会把自己的bi项目放在一个篮子里。在这种情况下，如果甲方能有较强的技术实力，能把两个乙方共同协作的项目管理起来，楼主说的这种问题应该就不会出现。如果甲方不能控制项目，那么这种问题就要由两个乙方来协商解决。

很多bi工具是有局限性的，像我们使用的cognos reportnet来说，能在工具里做表连接（对外连接支持有限），汇总分组也能做，但不支持在工具中嵌套子查询，也不支持在工具中画数据分析线（比如最小二乘法拟合）。所以这些工作必须后台去做。

我觉得一个项目要做得好，前端和后端要相互配合，互相推诿只能导致项目失败，或者造成日后维护的困难，最后只能影响公司的声誉。

innovate 20061106

我觉得DW&BI界应该制定出一套标准来,
比如后台模型设计到什么程度,
前端工具应该负责到什么程度. 现在都不清楚,
当然谁也没有标准去判断了.
我现在接触的客户，据说客户中高层领导就说Cognos
ReportNet这能做, 那也能做, 如果真是这样,
那倒真的可以把DW的建设费给省了,
问题是这个BI工具有那么厉害么?
不知道客户是被售前洗脑了, 还是他们自己搞过.
不过ReportNet不通过DW取数, 而直接取自业务系统的时候,
一个复杂点的报表需要运行半小时, 甚至1-多个小时,
真是有意思. 不过既然客户自己找咨询公司规划的,
以后才上DW, 所有条件都限制死了, 那也没办法,
能达到什么程度, 就只能达到什么程度了.
不过怀疑这家客户可能也会把未来的DW/BI项目分为两家或者多家公司去合作,
现在的咨询公司和BI厂商还真能忽悠.

li-zhenguo 20061107

我觉得单纯使用BI工具，而不在数据库中做必要的视图和汇总表，会显得比较困难和影响执行效率。拿reportnet来说吧，它提供一个界面模型让你拖拖拉拉生成元数据，但这个界面模型只支持明细层和汇总层，只允许在明细层做表连接，所以要实现复杂的嵌套子查询就只能在数据库中用视图实现了。然后它用你拖拖拉拉所得的元数据先生成cognos版的通用sql查询语句，然后根据连接数据库的类型再生成具体的sql语句，在这个过程中，无法设定hint（oracle的优化提示）去优化，也产生了一些比较笨的情况，具体见我的博客：
http://blog.tom.com/blog/read.php?bloggerid=828628&blogid=48562

从我的经验上来看，reportnet基于数据集市会比较好做些，如果用3nf的数据仓库做数据源，可能还需要另建视图或汇总表。

从什么都不能做到什么都能做，是一个对工具掌握的过程。从什么都能做到什么都不能做，是一个对工具进一步了解的过程。再从什么都不能做到知道什么能做什么不能做，是一个对工具精通的过程。客户可能处于第二个过程，体会到了reportnet的好处，但没有理解它的实现模型，不知道它的局限性。最好能结合工具的特点，引导客户的需求，若要说一个工具能实现所有的功能，那是不可能的。

smileagain 20061107

> 从什么都不能做到什么都能做，是一个对工具掌握的过程。从什么都能做到什么都不能做，是一个对工具进一步了解的过程。再从什么都不能做到知道什么能做什么不能做，是一个对工具精通的过程。客户可能处于第二个过程，体会到了reportnet的好处，但没有理解它的实现模型，不知道它的局限性。最好能结合工具的特点，引导客户的需求，若要说一个工具能实现所有的功能，那是不可能的。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友