一次对DWBI反思引出的真实故事(我的经历)
17 views
Skip to first unread message
interstage
May 8, 2008, 1:10:58 AM5/8/08
to ttnn BI 观点
现在有个牛人动不动把他所谓的成功项目经验(500强企业的DWBI,几个T的数据量)挂在嘴边,以来证明他创新所谓混合的ODS-EDW-CDW-
DM架构的先进性. 当我提出质疑的时候,他就把我归纳成业务派,说我什么技术外行等等. 我一般情况下不对别人的项目做评价,因为我觉得不礼貌,毕竟
DWBI都比较大,一定有别人的心血在里面,都有可学习可参照的地方. 所以,今天这个主题也是如此,我只对我自己对DWBI项目反思,谈谈我这段时间
的经历.
正在因为02年底对这个问题的思考和实践,使我从一个技术人员(数据库厂商的技术人员)开始了职业的变化,从BI技术人员到BI项目咨询,从BI项目咨
询到BI项目销售,从BI项目销售到目前业务运营管理者.期间跨度6年,就是因为对DWBI项目反思开始的,这个经历我觉得不应该是口头说说吧.我希望
大家能尊重一下我的经历,毕竟是用我的人生职场为代价,6年时间不短,如果化心思可以让很多女性接受你做为她的追求者.
98年,当我作为技术人员接触DW的时候,几年内看到的成功案例描述一般为如此:一张没有上DWBI项目前该企业非常痛苦的PPT，一张牛比的架构(研
究后基本上是类似于inmon的CIF架构)PPT，然后几张项目实施过程阶段性回顾PPT，接着是项目实现后的效果介绍PPT（多少量的数据，多少人
在用，多少张报表，多么开心）等等，曾经有一段时间看到这些成功案例，我都会很兴奋，接着很想去了解这个案例的架构中仓库模型的设计，元数据是如何管
理，ETL的数据上传规则定义和流程管理，ODS在这个架构的价值和定义方式，甚至想了解这个案例的项目实施方法，用什么样的软件产品，这些软件产品在
功能上能在这个项目实施起什么作用等等，一边研究，一边找资料，尽量在自己实施的项目去采用这些经验。自己作完项目后也按照这个成功案例进行描述，告诉
别人，真的是不亦乐乎。
DM架构的先进性. 当我提出质疑的时候,他就把我归纳成业务派,说我什么技术外行等等. 我一般情况下不对别人的项目做评价,因为我觉得不礼貌,毕竟
DWBI都比较大,一定有别人的心血在里面,都有可学习可参照的地方. 所以,今天这个主题也是如此,我只对我自己对DWBI项目反思,谈谈我这段时间
的经历.
正在因为02年底对这个问题的思考和实践,使我从一个技术人员(数据库厂商的技术人员)开始了职业的变化,从BI技术人员到BI项目咨询,从BI项目咨
询到BI项目销售,从BI项目销售到目前业务运营管理者.期间跨度6年,就是因为对DWBI项目反思开始的,这个经历我觉得不应该是口头说说吧.我希望
大家能尊重一下我的经历,毕竟是用我的人生职场为代价,6年时间不短,如果化心思可以让很多女性接受你做为她的追求者.
98年,当我作为技术人员接触DW的时候,几年内看到的成功案例描述一般为如此:一张没有上DWBI项目前该企业非常痛苦的PPT，一张牛比的架构(研
究后基本上是类似于inmon的CIF架构)PPT，然后几张项目实施过程阶段性回顾PPT，接着是项目实现后的效果介绍PPT（多少量的数据，多少人
在用，多少张报表，多么开心）等等，曾经有一段时间看到这些成功案例，我都会很兴奋，接着很想去了解这个案例的架构中仓库模型的设计，元数据是如何管
理，ETL的数据上传规则定义和流程管理，ODS在这个架构的价值和定义方式，甚至想了解这个案例的项目实施方法，用什么样的软件产品，这些软件产品在
功能上能在这个项目实施起什么作用等等，一边研究，一边找资料，尽量在自己实施的项目去采用这些经验。自己作完项目后也按照这个成功案例进行描述，告诉
别人，真的是不亦乐乎。
interstage
May 8, 2008, 1:13:38 AM5/8/08
to ttnn BI 观点
一直到02年，我发现一个现象，我们看到这样描述的BIDW项目成功案例，在实际和业务部门交流中，都听到不同意见，从他们的口里基本上是失败的，最早
的解释方式是基于这个架构的项目思路是先进的，只是企业管理和员工水平未达到这个项目设计的思路而已。但后来不行了，觉得太对不起别人了，别人水平就这
些，管理机制就这样，我们所谓的那个设计思路是不是符合我们企业的发展。甚至我们的项目设计思路是不是真的先进，我们也不知道。
02年年底的一个晚上，有个很要好的MM，在网上问我，对EXCEL熟悉吗，她加班在搞一张KPI报表，中层领导要看汇总，主管领导要看明细，她在做，
在EXCEL计算逻辑搞不定，需要我帮助。我当时就说你们应该上套BI项目，她告诉我，上了，是某个牛比公司做的，半年了，业务部门基本不用，报表每月
还是自己做。然后她把报表传给我了，我化了2个小时终于想出了计算逻辑，因为我不懂宏编程，我一直在说如果在数据库端做了存储过程，她的逻辑很快实现，
她对数据库一点不懂，所以一直限制在EXCEL计算逻辑上。当做完这个MM的要求后，我以欣赏的眼光去看EXCEL报表的，突然发现了一个奇怪的情况：
扔掉哪些花哨的格式，报表中所有表恻或者表头的描述都可以是数据库的纬度，都中间的数据量（含计算）都可以是数据库的事实表。于是乎，我开始反思我们以
前DWBI的项目实施思路了，我们一上来搞架构，设计仓库模型，定义元数据管理等等，觉得只要数据仓库架构牛比，任何报表内容都可以做出现，报表内容做
不出来，一定是架构没做的更精细等等。我们实在太技术化了，所以，在03年，我涉及到的项目实施方式开始变化了，因为不管什么分析，载体一定是报表和报
表延伸出来的图，核心还是报表，于是做项目的时候，先找大老板谈KPI（期间学习了BSC和杜邦分析法），再找业务部门要目前所需要的所有分析报表，把
然后根据这些报表，定义归纳出报表样式， 到表样式完成后，原则上表恻或者表头的描述都是数据库的纬度 ， 而非表恻或者表头数据原则上是数据仓库的事
实表， 这样，再进行数据仓库模型设计， 有时候表恻或者表头的描述和数据库的纬度不能完全匹配的话，就利用元数据管理来实现。设计完仓库模型后，再选
择DW合适架构，设计ODS和定义ETL规则和流程。我并不反对架构，但我觉得我实施这个方法只是选择什么样架构问题，谈不上创造出新的架构，因为我觉
得我达到到Inmon或者Kimball的境界，而且我选择架构不需要和用户讨论了，架构已经成为实现DWBI项目的工具了，用户其实不会关注架构，只
关心要化多少钱。这是我第一次改变实施方式的项目经历，结果至少业务部门满意了，当业务部门满意，领导的KPI做的差点其实没问题。
的解释方式是基于这个架构的项目思路是先进的，只是企业管理和员工水平未达到这个项目设计的思路而已。但后来不行了，觉得太对不起别人了，别人水平就这
些，管理机制就这样，我们所谓的那个设计思路是不是符合我们企业的发展。甚至我们的项目设计思路是不是真的先进，我们也不知道。
02年年底的一个晚上，有个很要好的MM，在网上问我，对EXCEL熟悉吗，她加班在搞一张KPI报表，中层领导要看汇总，主管领导要看明细，她在做，
在EXCEL计算逻辑搞不定，需要我帮助。我当时就说你们应该上套BI项目，她告诉我，上了，是某个牛比公司做的，半年了，业务部门基本不用，报表每月
还是自己做。然后她把报表传给我了，我化了2个小时终于想出了计算逻辑，因为我不懂宏编程，我一直在说如果在数据库端做了存储过程，她的逻辑很快实现，
她对数据库一点不懂，所以一直限制在EXCEL计算逻辑上。当做完这个MM的要求后，我以欣赏的眼光去看EXCEL报表的，突然发现了一个奇怪的情况：
扔掉哪些花哨的格式，报表中所有表恻或者表头的描述都可以是数据库的纬度，都中间的数据量（含计算）都可以是数据库的事实表。于是乎，我开始反思我们以
前DWBI的项目实施思路了，我们一上来搞架构，设计仓库模型，定义元数据管理等等，觉得只要数据仓库架构牛比，任何报表内容都可以做出现，报表内容做
不出来，一定是架构没做的更精细等等。我们实在太技术化了，所以，在03年，我涉及到的项目实施方式开始变化了，因为不管什么分析，载体一定是报表和报
表延伸出来的图，核心还是报表，于是做项目的时候，先找大老板谈KPI（期间学习了BSC和杜邦分析法），再找业务部门要目前所需要的所有分析报表，把
然后根据这些报表，定义归纳出报表样式， 到表样式完成后，原则上表恻或者表头的描述都是数据库的纬度 ， 而非表恻或者表头数据原则上是数据仓库的事
实表， 这样，再进行数据仓库模型设计， 有时候表恻或者表头的描述和数据库的纬度不能完全匹配的话，就利用元数据管理来实现。设计完仓库模型后，再选
择DW合适架构，设计ODS和定义ETL规则和流程。我并不反对架构，但我觉得我实施这个方法只是选择什么样架构问题，谈不上创造出新的架构，因为我觉
得我达到到Inmon或者Kimball的境界，而且我选择架构不需要和用户讨论了，架构已经成为实现DWBI项目的工具了，用户其实不会关注架构，只
关心要化多少钱。这是我第一次改变实施方式的项目经历，结果至少业务部门满意了，当业务部门满意，领导的KPI做的差点其实没问题。
interstage
May 8, 2008, 1:17:14 AM5/8/08
to ttnn BI 观点
但是这样的实施方式好景也不长，因为业务部门报表一旦变化或者新报表出来，我需要进行进行项目后期维护的，这让我很痛苦，甚至怀疑我的方法是错误的，还
是想回来转成架构设计的精细上来。到05年，我看了伟大的品质大师戴明的管理理论和日本改善大师今井正明的管理书，一下子让我想清楚了，原来我们不可能
取代别人思维做分析，所以就不可能了解承担分析载体以--报表后所有的变化。于是我有意识的去找一些日本BI软件（我们所接触的BI软件基本上是美国
的，而美国软件的核心是创新理论），看看他们BI软件是否遵守戴明的品质管理和今井正明的改善管理，是不是遵守PDCA的原理。于是乎我发现原来作为分
析载体的报表制作可以被分解，可以以“持续改善”方式实现，利用管理视点将DW中的元数据管理和业务人员眼中的分析角度进行分解，而且适应业务人员对报
表变化的需求，而降低IT部门的实施压力。这样，我在05年转成项目销售，去劝服哪些准备上DWBI的企业采用我的实施模式，并告诉他们，企业组织架构
中不同人员所做的工作基本上是“创新”--“改善”—“规范化维持”三种工作方式，而这三种工作方式是不能取代的，而美国企业的管理方式就是在于“创
新”—“规范化维持”2种方式。所以基于”持续改善“的BI实施，我基本形成思路，并在06-07年连续说服5家企业用我的方式上BI项目。
到了07年底，我又发现一个问题，所以分析的价值都是基于数据的，而数据采集的工作，我们仅仅通过模型设计好后靠ETL定义流程方式就可以了吗，而且分
析报表的变化，往往是表样出来了，数据仓库里没数据，ETL没有设计这个采集工作。而未来的数据采集在于移动采集。所以我关注这个方面的方向，我加入了
一家公司，我认为这样公司目前做的事情在未来是可以实现移动数据采集的。进款目前我的职位和我的方向并不一致，是让我做一个中移动全网业务运营管理，天
天和31个省市场部交流，天天看报表，分析报表，查问题，对BOSS系统的数据质量提出修改意见，已经深刻体会到基于数据分析的业务运营人员的辛酸苦
辣。
这就是我从DWBI项目反思的经历，有牛人说我没有DWBI项目经验，一直在鼓吹他所谓混合架构，我相信架构的创新绝对不是靠你这个项目研究和技术研究
能做出来的，一定要靠整体系统思维(企业管理文化,组织架构,IT现状,DWBI的技术发展)才能创造并验证，而这个条件在中国企业中目前其实并不成
熟，没有伟大的企业，就不可能产生伟大的创新，我相信DW的架构也是如此。
是想回来转成架构设计的精细上来。到05年，我看了伟大的品质大师戴明的管理理论和日本改善大师今井正明的管理书，一下子让我想清楚了，原来我们不可能
取代别人思维做分析，所以就不可能了解承担分析载体以--报表后所有的变化。于是我有意识的去找一些日本BI软件（我们所接触的BI软件基本上是美国
的，而美国软件的核心是创新理论），看看他们BI软件是否遵守戴明的品质管理和今井正明的改善管理，是不是遵守PDCA的原理。于是乎我发现原来作为分
析载体的报表制作可以被分解，可以以“持续改善”方式实现，利用管理视点将DW中的元数据管理和业务人员眼中的分析角度进行分解，而且适应业务人员对报
表变化的需求，而降低IT部门的实施压力。这样，我在05年转成项目销售，去劝服哪些准备上DWBI的企业采用我的实施模式，并告诉他们，企业组织架构
中不同人员所做的工作基本上是“创新”--“改善”—“规范化维持”三种工作方式，而这三种工作方式是不能取代的，而美国企业的管理方式就是在于“创
新”—“规范化维持”2种方式。所以基于”持续改善“的BI实施，我基本形成思路，并在06-07年连续说服5家企业用我的方式上BI项目。
到了07年底，我又发现一个问题，所以分析的价值都是基于数据的，而数据采集的工作，我们仅仅通过模型设计好后靠ETL定义流程方式就可以了吗，而且分
析报表的变化，往往是表样出来了，数据仓库里没数据，ETL没有设计这个采集工作。而未来的数据采集在于移动采集。所以我关注这个方面的方向，我加入了
一家公司，我认为这样公司目前做的事情在未来是可以实现移动数据采集的。进款目前我的职位和我的方向并不一致，是让我做一个中移动全网业务运营管理，天
天和31个省市场部交流，天天看报表，分析报表，查问题，对BOSS系统的数据质量提出修改意见，已经深刻体会到基于数据分析的业务运营人员的辛酸苦
辣。
这就是我从DWBI项目反思的经历，有牛人说我没有DWBI项目经验，一直在鼓吹他所谓混合架构，我相信架构的创新绝对不是靠你这个项目研究和技术研究
能做出来的，一定要靠整体系统思维(企业管理文化,组织架构,IT现状,DWBI的技术发展)才能创造并验证，而这个条件在中国企业中目前其实并不成
熟，没有伟大的企业，就不可能产生伟大的创新，我相信DW的架构也是如此。
wikicc
May 8, 2008, 1:34:01 AM5/8/08
to tt...@googlegroups.com
每个人的经历都是别人无法复制的，
这个世界上为什么会千姿百态，因为各自的境遇、机会，能力千差万别。
现在企业都在要求协同， 社会要求和谐， ttnn也需要这种"协心"的氛围。
前段时间qing总结帖子，说ttnn就大部分是三个人在发帖.
这不得不让我们思考一个问题，
"强者"的声音已经盖过"弱者的声音"。
很多人都在"弱弱"的问，这个ttnn文化可不好。
ttnn也绝不是三家之言。
希望qing闲时能考虑这个问题。
这个世界上为什么会千姿百态，因为各自的境遇、机会，能力千差万别。
现在企业都在要求协同， 社会要求和谐， ttnn也需要这种"协心"的氛围。
前段时间qing总结帖子，说ttnn就大部分是三个人在发帖.
这不得不让我们思考一个问题，
"强者"的声音已经盖过"弱者的声音"。
很多人都在"弱弱"的问，这个ttnn文化可不好。
ttnn也绝不是三家之言。
希望qing闲时能考虑这个问题。
Qing
May 8, 2008, 1:55:45 AM5/8/08
to tt...@googlegroups.com
咳咳！被点名了。
其实我考虑过这个问题。
和谐，不是ttnn的追求，
自由、开放才是。
没有人强制要求这里是什么声音
不能有什么声音
看到interstage十年精彩BI路
每个人的经历都不同
每个人有每个人的生活
每个人有每个人的工作
每个人有每个人的精彩
interstage
May 8, 2008, 1:56:29 AM5/8/08
to ttnn BI 观点
呵呵,我的经历变化其实就是我对DWBI项目不断反思和持续学习的过程.至于和谐,我赞同,和谐是在于求同存异,并不是不允许观点碰撞.可能让别人完全
接受你的观念很难,但在观点碰撞中的自我修正也是快速学习的一种方式.所以我问Qing什么是水贴,既然交流,一定是深入碰撞后才会深刻.这个是不变
的,不然QING在写魔星的时候,为什么要把男女之间的性写上去,就是因为他们深刻碰撞了,哈哈.当然我和牛人不会出现这个情况,除非牛人是一个漂亮
MM,所以让牛人深刻一定要他在观念上碰撞.
至于你说的TTNN三个发贴人,我不是其中一个,我很喜新的人,但我不厌旧,过段时间,我会在TTNN出现,交流一下,然后继续干其他事情,主要是这几
天每天晚上写文挡到3-4点,精力旺盛中,又上来交流一下罢了.发贴的人不一定是"强者",不发贴的人不一定是"弱者",在争论中,声音大的人不一定有
道理,我的观念不一定全对,真正坚持自己观念不断去修正和实践的人才是"强者".才是值得尊重的.牛人的坚持,也是值得尊重的.但希望他在坚持中不断的
修正.为了一个目标而坚持的人永远值得别人去尊重,而不是那些金钱,权势和地位.每个人的境遇、机会，能力千差万别,但每个人的心一定是自由的.这才是
我本贴的主题思想.
接受你的观念很难,但在观点碰撞中的自我修正也是快速学习的一种方式.所以我问Qing什么是水贴,既然交流,一定是深入碰撞后才会深刻.这个是不变
的,不然QING在写魔星的时候,为什么要把男女之间的性写上去,就是因为他们深刻碰撞了,哈哈.当然我和牛人不会出现这个情况,除非牛人是一个漂亮
MM,所以让牛人深刻一定要他在观念上碰撞.
至于你说的TTNN三个发贴人,我不是其中一个,我很喜新的人,但我不厌旧,过段时间,我会在TTNN出现,交流一下,然后继续干其他事情,主要是这几
天每天晚上写文挡到3-4点,精力旺盛中,又上来交流一下罢了.发贴的人不一定是"强者",不发贴的人不一定是"弱者",在争论中,声音大的人不一定有
道理,我的观念不一定全对,真正坚持自己观念不断去修正和实践的人才是"强者".才是值得尊重的.牛人的坚持,也是值得尊重的.但希望他在坚持中不断的
修正.为了一个目标而坚持的人永远值得别人去尊重,而不是那些金钱,权势和地位.每个人的境遇、机会，能力千差万别,但每个人的心一定是自由的.这才是
我本贴的主题思想.
wikicc
May 8, 2008, 3:25:10 AM5/8/08
to tt...@googlegroups.com
记得博弈论中有"动态贝叶斯修正"的内容，是根据对手的策略而不断改变自身策略，最后使得团体获得最优，而不是个体最优。
我赞成interstage的求同存异和用于个人和企业的"持续改善"。
和谐是需要的，和谐不是让大家只有一个声音。和谐在于不同声音的碰撞。
TTNN作为 BI媒体不在于其本身自由和开放，而是在于对内容的克制，对帖子高质量的追求。
"水贴"是自由的， 少数声音，不管是强的还是弱的，大的小的。这都不符合TTNN的初衷。
作为TTNN的发起人，最大的责任是"倡导"和"克制"这种自由和开放，还要促进个体之间的碰撞。
我赞成interstage的求同存异和用于个人和企业的"持续改善"。
和谐是需要的，和谐不是让大家只有一个声音。和谐在于不同声音的碰撞。
TTNN作为 BI媒体不在于其本身自由和开放，而是在于对内容的克制，对帖子高质量的追求。
"水贴"是自由的， 少数声音，不管是强的还是弱的，大的小的。这都不符合TTNN的初衷。
作为TTNN的发起人，最大的责任是"倡导"和"克制"这种自由和开放，还要促进个体之间的碰撞。
syfins
May 8, 2008, 3:26:01 AM5/8/08
to ttnn BI 观点
"我相信架构的创新绝对不是靠你这个项目研究和技术研究
能做出来的，一定要靠整体系统思维(企业管理文化,组织架构,IT现状,DWBI的技术发展)才能创造并验证，而这个条件在中国企业中目前其实并不
成
熟，没有伟大的企业，就不可能产生伟大的创新，我相信DW的架构也是如此。 "
赞这句话
来讲讲俺对这一段争论的看法：
唯物主义告诉我们，一切从实际出发
两个在没有具体case的情况下来谈架构，基本就是扯蛋，除了看些火爆的场面，其它就是涨涨见识
“存在即合理”
多种架构本来就大量存在，都是工具运用，都是在达到一个共同目的下的不同解决方法
只存在在具体情况下谁应用好的问题
为什么非要有人对别人的架构指三说四呢
去粗取精去伪存真
没必要全盘否定谁看不起谁
辩证主义还是最大的法宝
能做出来的，一定要靠整体系统思维(企业管理文化,组织架构,IT现状,DWBI的技术发展)才能创造并验证，而这个条件在中国企业中目前其实并不
成
熟，没有伟大的企业，就不可能产生伟大的创新，我相信DW的架构也是如此。 "
赞这句话
来讲讲俺对这一段争论的看法：
唯物主义告诉我们，一切从实际出发
两个在没有具体case的情况下来谈架构，基本就是扯蛋，除了看些火爆的场面，其它就是涨涨见识
“存在即合理”
多种架构本来就大量存在，都是工具运用，都是在达到一个共同目的下的不同解决方法
只存在在具体情况下谁应用好的问题
为什么非要有人对别人的架构指三说四呢
去粗取精去伪存真
没必要全盘否定谁看不起谁
辩证主义还是最大的法宝
raullew
May 8, 2008, 3:33:03 AM5/8/08
to ttnn BI 观点
基本上赞同你的这三段文字，都是辛酸泪啊
interstage
May 8, 2008, 3:35:46 AM5/8/08
to ttnn BI 观点
呵呵，我赞同你对ＴＴＮＮ不支持水贴的批判，现在我对水贴的理解（其实我也知道这个概念才２天）是因为ＱＩＮＧ无法作到水贴自动判断而会引起垃圾邮件的
群发，其实，我觉得这个是技术的问题，你不能因为技术上没这个功能，而否定别人的这个权力．当然ＴＴＮＮ有自己的规则，我觉得可以求同存异，探讨一下技
术实现．首先抛一下砖，编一个简单逻辑：
１，字数小于１０之内，＂顶＂，＂赞同＂等字占比为４０％，不做邮件发送
２，字数小于２０之内，＂顶＂，＂赞同＂等字占比为３０％，不做邮件发送
３，字数＞２０，原则同意邮件发送．
群发，其实，我觉得这个是技术的问题，你不能因为技术上没这个功能，而否定别人的这个权力．当然ＴＴＮＮ有自己的规则，我觉得可以求同存异，探讨一下技
术实现．首先抛一下砖，编一个简单逻辑：
１，字数小于１０之内，＂顶＂，＂赞同＂等字占比为４０％，不做邮件发送
２，字数小于２０之内，＂顶＂，＂赞同＂等字占比为３０％，不做邮件发送
３，字数＞２０，原则同意邮件发送．
wikicc
May 8, 2008, 3:51:27 AM5/8/08
to tt...@googlegroups.com
其实QING已经在做了，他做统计的目的就在于防止这种水贴的发生，希望大家看到TTNN的现状，共同遵守和维护。
在这方面，我记得由一个叫做""罗伯特议事规则"，用于保证开会的有效，他的一些思想可以借鉴，但是那个又过于严肃。
TTNN也可以定一些基本的规则，规则内容尽量简单、不超过10条。 不会因为规则太多，伤害大家的积极性又能保证高效、高质量的交流。
在这方面，我记得由一个叫做""罗伯特议事规则"，用于保证开会的有效，他的一些思想可以借鉴，但是那个又过于严肃。
TTNN也可以定一些基本的规则，规则内容尽量简单、不超过10条。 不会因为规则太多，伤害大家的积极性又能保证高效、高质量的交流。
George Zhang
May 8, 2008, 4:02:34 AM5/8/08
to tt...@googlegroups.com
顶死你你你你你你你你你你你你你你你你你你你你你你你你你你你
看，防spam我们不专业～
--
Best Regard
George Zhang
看，防spam我们不专业～
2008/5/8 interstage <buer...@gmail.com>:
呵呵，我赞同你对ＴＴＮＮ不支持水贴的批判，现在我对水贴的理解（其实我也知道这个概念才２天）是因为ＱＩＮＧ无法作到水贴自动判断而会引起垃圾邮件的
群发，其实，我觉得这个是技术的问题，你不能因为技术上没这个功能，而否定别人的这个权力．当然ＴＴＮＮ有自己的规则，我觉得可以求同存异，探讨一下技
术实现．首先抛一下砖，编一个简单逻辑：
１，字数小于１０之内，＂顶＂，＂赞同＂等字占比为４０％，不做邮件发送
２，字数小于２０之内，＂顶＂，＂赞同＂等字占比为３０％，不做邮件发送
３，字数＞２０，原则同意邮件发送．
--
Best Regard
George Zhang
interstage
May 8, 2008, 4:06:17 AM5/8/08
to ttnn BI 观点
美国人的DWBI项目实施是＂创新＂＋＂规范化工作模型＂，所以能产生ＤＷＢＩ产品和架构创新大师
日本人的DWBI项目实施是＂创新＂＋＂改善＂＋＂规范化工作模型＂，所以能产生ＤＷＢＩ产品品质大师
我们的ＤＷＢＩ项目，是拿着所谓的混合架构，做到哪里算哪里，所以能产生ＤＷＢＩ项目的忽悠大师．
牛人还算令人尊重，至少只是在混合架构中坚持着，现在中国出现了另一个忽悠大师，自称为＂中国ＢＩ之父＂广州尚南科技有限公司总裁，阮夏名先生。哎，太
可怕了，这样下去，我们真的只能继续忽悠了．要么自己变傻，要么把别人变傻．
> > 熟，没有伟大的企业，就不可能产生伟大的创新，我相信DW的架构也是如此。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
日本人的DWBI项目实施是＂创新＂＋＂改善＂＋＂规范化工作模型＂，所以能产生ＤＷＢＩ产品品质大师
我们的ＤＷＢＩ项目，是拿着所谓的混合架构，做到哪里算哪里，所以能产生ＤＷＢＩ项目的忽悠大师．
牛人还算令人尊重，至少只是在混合架构中坚持着，现在中国出现了另一个忽悠大师，自称为＂中国ＢＩ之父＂广州尚南科技有限公司总裁，阮夏名先生。哎，太
可怕了，这样下去，我们真的只能继续忽悠了．要么自己变傻，要么把别人变傻．
>
> - 显示引用的文字 -
interstage
May 8, 2008, 4:09:29 AM5/8/08
to ttnn BI 观点
哈哈，我刚才算法只是抛砖，我相信ＱＩＮＧ和其他人会比我聪明，想出更好的算法．
On 5月8日, 下午4时02分, "George Zhang" <birdzhangxi...@gmail.com> wrote:
> 顶死你你你你你你你你你你你你你你你你你你你你你你你你你你你
>
> 看，防spam我们不专业～
>
> 2008/5/8 interstage <buer0...@gmail.com>:
On 5月8日, 下午4时02分, "George Zhang" <birdzhangxi...@gmail.com> wrote:
> 顶死你你你你你你你你你你你你你你你你你你你你你你你你你你你
>
> 看，防spam我们不专业～
>
赵一帆
May 8, 2008, 4:36:38 AM5/8/08
to tt...@googlegroups.com
看到前辈们惹火朝天的讨论，真的受益匪浅，让我这个井底之蛙了解到原来BI的理论原来有这么多，谢谢了！！！！
George Zhang
May 8, 2008, 4:37:07 AM5/8/08
to tt...@googlegroups.com
http://www.236z.com/redirect.php?tid=429150&goto=newpost
上面是版主讨论如何防垃圾贴的
结论是没有太好的办法
这个和垃圾邮件一样的，可以成为一个产业了
所以我说要从内容上防水贴是不太可行的，人大公司都要搞好久
最简单的还是管理用户，删号是最有效了，还有什验证码的上面那个链接也讲到
另外我觉得，水贴就像每天上班和同事们说早安一样
你如果觉得每天重复一样的话很无聊，那么你见到朋友都不打招呼吗？
所以我的观点是，水贴不可怕，可怕的是恶劣用户无度的捣乱
所以我的建议是维持一个好的用户群，其他可以暂时不管
看图说话 blog ***
http://godcode.yupoo.com
黑白暗房 *****
http://birdzhangxiang.spaces.live.com
上面是版主讨论如何防垃圾贴的
结论是没有太好的办法
这个和垃圾邮件一样的，可以成为一个产业了
所以我说要从内容上防水贴是不太可行的，人大公司都要搞好久
最简单的还是管理用户，删号是最有效了，还有什验证码的上面那个链接也讲到
另外我觉得，水贴就像每天上班和同事们说早安一样
你如果觉得每天重复一样的话很无聊，那么你见到朋友都不打招呼吗？
所以我的观点是，水贴不可怕，可怕的是恶劣用户无度的捣乱
所以我的建议是维持一个好的用户群，其他可以暂时不管
2008/5/8 interstage <buer...@gmail.com>:
http://godcode.yupoo.com
黑白暗房 *****
http://birdzhangxiang.spaces.live.com
shiming
May 8, 2008, 9:21:58 AM5/8/08
to tt...@googlegroups.com
falcon
May 8, 2008, 9:54:39 AM5/8/08
to ttnn BI 观点
赞同。个人觉得解决业务问题比纯考虑技术架构要重要。现在经常是做一个严格按照架构来设计的项目，发现业务并不怎么使用，而有一些比较简单紧急且有实际
用途的需求，因为考虑架构而不实现。不过，没有好的架构，确实维护上也比较麻烦的，矛盾啊。。
报表制作分解和“持续改善”方式？挺新鲜的。准备好好体会一下，嘿嘿
用途的需求，因为考虑架构而不实现。不过，没有好的架构，确实维护上也比较麻烦的，矛盾啊。。
报表制作分解和“持续改善”方式？挺新鲜的。准备好好体会一下，嘿嘿
interstage
May 10, 2008, 9:13:16 AM5/10/08
to ttnn BI 观点
谢谢支持．这几天正在完善＂持续改善＂的业务运营模式，准备先向公司推广，然后提交给中移动集团，要求目前对我管理的一个全网运营业务，按照这个"持续
改善"业务运营模式来实施．
如果，你对我的＂持续改善＂的DWBI项目实施方法感兴趣，我也可以完善一下，准备把它定义为＂持续改善架构＂,本来他能叫"混合架构",我的估计叫什
么架构也肯定没问题,当然为了对Inmon和Kimball大师的尊重,我还是把它叫"持续改善模型",这个＂持续改善模型＂以ETL-ODS-
CDW-DM为组件(目前版本还不考虑用EDW,因为我发现连中移动的BOSS系统也没达到EDW,估计目前在中国企业还没有一家公司在IT投入上超过
中移动,在未来版本会加入EDW的组件,会调整组件间的拓扑图),以"管理视点"模型来融合DW中的纬度和业务人员眼中的分析角度,工作方式的定义:
1,IT部门的工作方式(聚焦在DW建设);2,业务部门的工作方式(聚焦在分析报表制作). 通过PDCA(SDCA)的管理方式(定义出规范性文
档).
但这个需要很多时间,许多精力去完成这个模型,也不是我一个人都能全部完成(因为模型含技术组件和管理方式,需要不同的专家进行共享和支持),需要
TTNN的Biers多帮助我,一起完成,谢谢!!
改善"业务运营模式来实施．
如果，你对我的＂持续改善＂的DWBI项目实施方法感兴趣，我也可以完善一下，准备把它定义为＂持续改善架构＂,本来他能叫"混合架构",我的估计叫什
么架构也肯定没问题,当然为了对Inmon和Kimball大师的尊重,我还是把它叫"持续改善模型",这个＂持续改善模型＂以ETL-ODS-
CDW-DM为组件(目前版本还不考虑用EDW,因为我发现连中移动的BOSS系统也没达到EDW,估计目前在中国企业还没有一家公司在IT投入上超过
中移动,在未来版本会加入EDW的组件,会调整组件间的拓扑图),以"管理视点"模型来融合DW中的纬度和业务人员眼中的分析角度,工作方式的定义:
1,IT部门的工作方式(聚焦在DW建设);2,业务部门的工作方式(聚焦在分析报表制作). 通过PDCA(SDCA)的管理方式(定义出规范性文
档).
但这个需要很多时间,许多精力去完成这个模型,也不是我一个人都能全部完成(因为模型含技术组件和管理方式,需要不同的专家进行共享和支持),需要
TTNN的Biers多帮助我,一起完成,谢谢!!
Delin He
May 10, 2008, 10:49:24 PM5/10/08
to tt...@googlegroups.com
从来只听你在说"持续改善"四个字， 如何持续，如何改善，不要让大家听着还是忽悠居多？ 还请详加解释一下，给个例子？
在08-5-10，interstage <buer...@gmail.com> 写道：
Steven
May 10, 2008, 10:55:50 PM5/10/08
to tt...@googlegroups.com
同样想法，记得interstage
上次说给一些案例和介绍，是否能就BI系统的规划，用“持续改善”的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建设，企业价值在何处等等，希望能看到一个很明确很清晰的思路和想法
2008-05-11
Steven
发件人： Delin He
发送时间： 2008-05-11 10:49:44
抄送：
主题： Re: 一次对DWBI反思引出的真实故事(我的经历)
innovate511
May 11, 2008, 1:01:42 AM5/11/08
to ttnn BI 观点
时过几天，不知道楼主还认为技术在DWBI的重要性还是那么一点点么？什么动不动就是抬出500强企业的案例，难道人家建设了10年以上的案例，有那么
多经验教训我们不该去借鉴以反思我们项目中的瓶颈和弯路么？
持续改善的BI建设，楼主只是从业务角度去考虑，而我更多是从技术角度去考虑，技术是对BI分析的支撑根本，没有技术的支持，我看BI业务持续改善的分
析能延续到几年，1、2年还是2、3年，之后怎么持续改善？
正如我提到过很多企业通过计划、预测系统（他们的数据源来自DW或DM），进行计划和预测后，结果返回到DW，和现实的历史的数据进行模型上的融合，对
照着现实数据分析，调整计划和预测算法，达到持续改善的模型技术支撑，试想没有这些技术上的支持，持续改善不是空中楼阁么？
某些资深人士在业务方面有相当的钻研，但毕竟业务只是BI中的重要部分之一，另外重要的就是技术支撑，而且对于国外先进的技术支撑经验还不削，是否觉得
我们中国的BI，有持续改善的BI分析思路和管理方法即可，技术上可以随便，照搬Kimball的多维数据仓库理论或者行业模型产品即可，于是说DW架
构不过如此，大家重点钻研业务持续改善即可搞好BI。其实我可以明确的说，即便是Kimball亲自指导的项目，其技术细节远远超过了他在书中描述的内
容，他书中仅仅描述的是中心思想，确实比较全面，但设计和实施细节上对于项目的指导还远远不够。
我很欣赏在某些方面钻研很深的BIer，对于业界交流上有很强的促进作用，只是观点不宜过于偏激，对于自己只是了解到，没有深入研究的领域，不要枉自下
结论。
我知道有的DW很资深的哥们（包括有的老外），对BI分析都是不削的，他们觉得BI分析没啥"技术含量"，说DW才是正道，DW变化多端，DW模型准备
好后，BI展现就很轻松。其实我也不赞同他们的观点，因为他们在BI分析上了解不够深，BI分析的重要性不在于展现。
On 5月11日, 上午10时55分, "Steven" <tanhm1...@gmail.com> wrote:
> 同样想法，记得interstage 上次说给一些案例和介绍，是否能就BI系统的规划，用"持续改善"的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建-设，企业价值在何处等等，希望能看到一个很明确很清晰的思路和想法
>
多经验教训我们不该去借鉴以反思我们项目中的瓶颈和弯路么？
持续改善的BI建设，楼主只是从业务角度去考虑，而我更多是从技术角度去考虑，技术是对BI分析的支撑根本，没有技术的支持，我看BI业务持续改善的分
析能延续到几年，1、2年还是2、3年，之后怎么持续改善？
正如我提到过很多企业通过计划、预测系统（他们的数据源来自DW或DM），进行计划和预测后，结果返回到DW，和现实的历史的数据进行模型上的融合，对
照着现实数据分析，调整计划和预测算法，达到持续改善的模型技术支撑，试想没有这些技术上的支持，持续改善不是空中楼阁么？
某些资深人士在业务方面有相当的钻研，但毕竟业务只是BI中的重要部分之一，另外重要的就是技术支撑，而且对于国外先进的技术支撑经验还不削，是否觉得
我们中国的BI，有持续改善的BI分析思路和管理方法即可，技术上可以随便，照搬Kimball的多维数据仓库理论或者行业模型产品即可，于是说DW架
构不过如此，大家重点钻研业务持续改善即可搞好BI。其实我可以明确的说，即便是Kimball亲自指导的项目，其技术细节远远超过了他在书中描述的内
容，他书中仅仅描述的是中心思想，确实比较全面，但设计和实施细节上对于项目的指导还远远不够。
我很欣赏在某些方面钻研很深的BIer，对于业界交流上有很强的促进作用，只是观点不宜过于偏激，对于自己只是了解到，没有深入研究的领域，不要枉自下
结论。
我知道有的DW很资深的哥们（包括有的老外），对BI分析都是不削的，他们觉得BI分析没啥"技术含量"，说DW才是正道，DW变化多端，DW模型准备
好后，BI展现就很轻松。其实我也不赞同他们的观点，因为他们在BI分析上了解不够深，BI分析的重要性不在于展现。
On 5月11日, 上午10时55分, "Steven" <tanhm1...@gmail.com> wrote:
> 同样想法，记得interstage 上次说给一些案例和介绍，是否能就BI系统的规划，用"持续改善"的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建-设，企业价值在何处等等，希望能看到一个很明确很清晰的思路和想法
>
interstage
May 11, 2008, 6:00:06 AM5/11/08
to ttnn BI 观点
你还不了解我对技术的执着和学习能力（这个能力肯定不在你之下），正是在经过几年对技术的研究发现无法突破，才认为我可能走错了．你把ＤＷ归纳为技术，
ＢＩ归纳为业务，这个归纳尽管不合事宜，但这样谈也可以．这就是我目前一直在问的问题，在文化和环境没有在中国形成前，技术的选择是不是为主要力量，正
如我们一直在问是业务为主导还是技术为主导一样．＂持续改善＂（已经升华到理论层面）起源于１９７０年，那时候ＲＤＢ的理论才出现，产品还没出现，ＤＷ
起源１９８５年，ＤＷ架构完善于２０００年（ＣＩＦ和ＭＤ的架构那时候才争论结束，完善起来，才８年时间，有人已经开始准备搞第３个架构），与＂持续改
善＂管理文化比起来，这个ＤＷ架构简直太年轻了，所以我一直认为技术发展太快速了，基于技术的架构远不如基于文化的管理和实施方式来的持久．我不敢说＂
持续改善＂（已经升华到理论层面）的管理文化能坚持到１００年，但我可以相信它的生命周期比你所谓的＂实践性混合架构＂（还没到理论层面）要长远的多．
没有技术的发展，业务管理推动力当然小很多，所以永远是某一个技术的生命周期短，业务管理的生命周期长．现在企业的管理文化从科层式的组织架构向扁平式
的组织架构转变走了近３００年，看看支撑这些管理文化计算机技术的生命周期吧．你前段时间不是在提＂云计算＂吗，不就是为了＂扁平式的组织架构＂的出现
提供新的技术架构．所以，研究技术本身是对的，但一定要做抬头拉车的人．
> > 同样想法，记得interstage 上次说给一些案例和介绍，是否能就BI系统的规划，用"持续改善"的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建--设，企业价值在何处等等，希望能看到一个很明确很清晰的思路和想法- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ＢＩ归纳为业务，这个归纳尽管不合事宜，但这样谈也可以．这就是我目前一直在问的问题，在文化和环境没有在中国形成前，技术的选择是不是为主要力量，正
如我们一直在问是业务为主导还是技术为主导一样．＂持续改善＂（已经升华到理论层面）起源于１９７０年，那时候ＲＤＢ的理论才出现，产品还没出现，ＤＷ
起源１９８５年，ＤＷ架构完善于２０００年（ＣＩＦ和ＭＤ的架构那时候才争论结束，完善起来，才８年时间，有人已经开始准备搞第３个架构），与＂持续改
善＂管理文化比起来，这个ＤＷ架构简直太年轻了，所以我一直认为技术发展太快速了，基于技术的架构远不如基于文化的管理和实施方式来的持久．我不敢说＂
持续改善＂（已经升华到理论层面）的管理文化能坚持到１００年，但我可以相信它的生命周期比你所谓的＂实践性混合架构＂（还没到理论层面）要长远的多．
没有技术的发展，业务管理推动力当然小很多，所以永远是某一个技术的生命周期短，业务管理的生命周期长．现在企业的管理文化从科层式的组织架构向扁平式
的组织架构转变走了近３００年，看看支撑这些管理文化计算机技术的生命周期吧．你前段时间不是在提＂云计算＂吗，不就是为了＂扁平式的组织架构＂的出现
提供新的技术架构．所以，研究技术本身是对的，但一定要做抬头拉车的人．
>
> - 显示引用的文字 -
interstage
May 11, 2008, 6:10:19 AM5/11/08
to ttnn BI 观点
呵呵，哎, 我讲了几个月,讲到戴明,讲到正井今明,一直在讲业务层面,你也不去查查,"改善"本来是企业的管理文化,全球有一个固定的英文单词
叫"Kaizen",它起源于1970年,现在是全球性各大公司基本上采用的管理方法(中国的企业除外).其中有很多新的方法,比如"第5项修炼"中的
学习型团队,比如TQM,TQC等等,如何持续，如何改善,已经很成熟了,你在google上一查,估计有400万条以上的资料.我在05年接触这个理
论后,把我的BI实施经验结合起来,提出了"持续改善"的BI实施方式,准备把这个方式上升到模型层面
On 5月11日, 上午10时49分, "Delin He" <beiji...@gmail.com> wrote:
> 从来只听你在说"持续改善"四个字， 如何持续，如何改善，不要让大家听着还是忽悠居多？ 还请详加解释一下，给个例子？
>
> 在08-5-10，interstage <buer0...@gmail.com> 写道：
> --- 隐藏被引用文字 -
>
> - 显示引用的文字 -
叫"Kaizen",它起源于1970年,现在是全球性各大公司基本上采用的管理方法(中国的企业除外).其中有很多新的方法,比如"第5项修炼"中的
学习型团队,比如TQM,TQC等等,如何持续，如何改善,已经很成熟了,你在google上一查,估计有400万条以上的资料.我在05年接触这个理
论后,把我的BI实施经验结合起来,提出了"持续改善"的BI实施方式,准备把这个方式上升到模型层面
On 5月11日, 上午10时49分, "Delin He" <beiji...@gmail.com> wrote:
> 从来只听你在说"持续改善"四个字， 如何持续，如何改善，不要让大家听着还是忽悠居多？ 还请详加解释一下，给个例子？
>
>
> - 显示引用的文字 -
interstage
May 11, 2008, 6:25:33 AM5/11/08
to ttnn BI 观点
"BI系统的规划，用"持续改善"的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建-设，企业价值在何处等
等"这些在我给出某个案例的PPT,"非技术层面的BI成功"2讲,都曾经描述过,你们可以在TTNN找到,可能那时候大家不当回事.
关于上升成"持续改善"BI模型的理论层面,这就是我在TTNN的最大目标,希望和TTNN的Bier一起合作把"持续改善"的BI模型搞出来,我可
以先把"持续改善"的理论展开,把基于"持续改善"的BI模型管理视点在技术定义描述,其他需要各位的智慧和精力把它完善,希望Qing单独起一个主
题,先讨论出BI模型理论定义,包含什么技术组件和管理方法,然后TTNN的Bier各自拿出所长,这个模型如果在理论层面完善了,建议公开给所有
BIer.
> 同样想法，记得interstage 上次说给一些案例和介绍，是否能就BI系统的规划，用"持续改善"的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建-设，企业价值在何处等等，希望能看到一个很明确很清晰的思路和想法
>
> 2008-05-11
>
> Steven
>
> - 显示引用的文字 -
等"这些在我给出某个案例的PPT,"非技术层面的BI成功"2讲,都曾经描述过,你们可以在TTNN找到,可能那时候大家不当回事.
关于上升成"持续改善"BI模型的理论层面,这就是我在TTNN的最大目标,希望和TTNN的Bier一起合作把"持续改善"的BI模型搞出来,我可
以先把"持续改善"的理论展开,把基于"持续改善"的BI模型管理视点在技术定义描述,其他需要各位的智慧和精力把它完善,希望Qing单独起一个主
题,先讨论出BI模型理论定义,包含什么技术组件和管理方法,然后TTNN的Bier各自拿出所长,这个模型如果在理论层面完善了,建议公开给所有
BIer.
> 同样想法，记得interstage 上次说给一些案例和介绍，是否能就BI系统的规划，用"持续改善"的角度来谈一个实际案例是怎么做的，花篇幅介绍应用现状，怎么持续改善，持续改善后对BI的建-设，企业价值在何处等等，希望能看到一个很明确很清晰的思路和想法
>
> 2008-05-11
>
> Steven
>
> 发件人： Delin He
> 发送时间： 2008-05-11 10:49:44
> 收件人： tt...@googlegroups.com
> 抄送：
> 主题： Re: 一次对DWBI反思引出的真实故事(我的经历)
>
> 从来只听你在说"持续改善"四个字， 如何持续，如何改善，不要让大家听着还是忽悠居多？ 还请详加解释一下，给个例子？
>
> 在08-5-10，interstage <buer0...@gmail.com> 写道：
> 发件人： Delin He
> 发送时间： 2008-05-11 10:49:44
> 收件人： tt...@googlegroups.com
> 抄送：
> 主题： Re: 一次对DWBI反思引出的真实故事(我的经历)
>
> 从来只听你在说"持续改善"四个字， 如何持续，如何改善，不要让大家听着还是忽悠居多？ 还请详加解释一下，给个例子？
>
> 谢谢支持．这几天正在完善＂持续改善＂的业务运营模式，准备先向公司推广，然后提交给中移动集团，要求目前对我管理的一个全网运营业务，按照这个"持续
> 改善"业务运营模式来实施．
> 如果，你对我的＂持续改善＂的DWBI项目实施方法感兴趣，我也可以完善一下，准备把它定义为＂持续改善架构＂,本来他能叫"混合架构",我的估计叫什
> 么架构也肯定没问题,当然为了对Inmon和Kimball大师的尊重,我还是把它叫"持续改善模型",这个＂持续改善模型＂以ETL-ODS-
> CDW-DM为组件(目前版本还不考虑用EDW,因为我发现连中移动的BOSS系统也没达到EDW,估计目前在中国企业还没有一家公司在IT投入上超过
> 中移动,在未来版本会加入EDW的组件,会调整组件间的拓扑图),以"管理视点"模型来融合DW中的纬度和业务人员眼中的分析角度,工作方式的定义:
> 1,IT部门的工作方式(聚焦在DW建设);2,业务部门的工作方式(聚焦在分析报表制作). 通过PDCA(SDCA)的管理方式(定义出规范性文
> 档).
>
> 但这个需要很多时间,许多精力去完成这个模型,也不是我一个人都能全部完成(因为模型含技术组件和管理方式,需要不同的专家进行共享和支持),需要
> TTNN的Biers多帮助我,一起完成,谢谢!!
>
> On 5月8日, 下午9时54分, falcon <falcon_...@hotmail.com> wrote:
>
>
>
> > 赞同。个人觉得解决业务问题比纯考虑技术架构要重要。现在经常是做一个严格按照架构来设计的项目，发现业务并不怎么使用，而有一些比较简单紧急且有实际
> > 用途的需求，因为考虑架构而不实现。不过，没有好的架构，确实维护上也比较麻烦的，矛盾啊。。
>
> > 报表制作分解和"持续改善"方式？挺新鲜的。准备好好体会一下，嘿嘿
>
> > On 5月8日, 下午1时10分, interstage <buer0...@gmail.com> wrote:- 隐藏被引用文字 -
> 改善"业务运营模式来实施．
> 如果，你对我的＂持续改善＂的DWBI项目实施方法感兴趣，我也可以完善一下，准备把它定义为＂持续改善架构＂,本来他能叫"混合架构",我的估计叫什
> 么架构也肯定没问题,当然为了对Inmon和Kimball大师的尊重,我还是把它叫"持续改善模型",这个＂持续改善模型＂以ETL-ODS-
> CDW-DM为组件(目前版本还不考虑用EDW,因为我发现连中移动的BOSS系统也没达到EDW,估计目前在中国企业还没有一家公司在IT投入上超过
> 中移动,在未来版本会加入EDW的组件,会调整组件间的拓扑图),以"管理视点"模型来融合DW中的纬度和业务人员眼中的分析角度,工作方式的定义:
> 1,IT部门的工作方式(聚焦在DW建设);2,业务部门的工作方式(聚焦在分析报表制作). 通过PDCA(SDCA)的管理方式(定义出规范性文
> 档).
>
> 但这个需要很多时间,许多精力去完成这个模型,也不是我一个人都能全部完成(因为模型含技术组件和管理方式,需要不同的专家进行共享和支持),需要
> TTNN的Biers多帮助我,一起完成,谢谢!!
>
> On 5月8日, 下午9时54分, falcon <falcon_...@hotmail.com> wrote:
>
>
>
> > 赞同。个人觉得解决业务问题比纯考虑技术架构要重要。现在经常是做一个严格按照架构来设计的项目，发现业务并不怎么使用，而有一些比较简单紧急且有实际
> > 用途的需求，因为考虑架构而不实现。不过，没有好的架构，确实维护上也比较麻烦的，矛盾啊。。
>
> > 报表制作分解和"持续改善"方式？挺新鲜的。准备好好体会一下，嘿嘿
>
>
> - 显示引用的文字 -
innovate511
May 11, 2008, 7:04:44 AM5/11/08
to ttnn BI 观点
个人感觉楼主理论性偏强，面太多，我对所有初入们的朋友都会提醒，一般BIDW需要从一个方向入手入门，然后广阅各种相关技术技能和管理方案，之后再精
通其中一个方向，达到DW架构师或者BI分析专家。
不知道楼主算精通哪一个方向呢？不过看起来精通BI方面多点，数据仓库方面在广度方面我觉得也足够了，但光是靠那么些理论和见识过的项目就下结论，是否
显得偏颇？
持续改善的BI系统是每一个派系每一个BI公司和个人都在追求的，并非仅仅是一个概念或者理论，通过一个模型来解决，目前还看不到有这个迹象和可能。就
我的经历来看，持续改善的BI系统应该是合理的数据仓库架构+企业信息化基础的不断完善+不断有新的计划、预测系统结合真实的数据进行企业某些方面的战
略（上层人员执行）、策略（中低层人员执行）调整（非历史的真实的数据）+持续改善的BI分析策略和方案，共4部分组成。
数据仓库架构是基础，它直接导致系统是否有高延续性、高稳定性和高扩展性，否则计划、预测数据如何和历史数据结合起来存储你都不清楚，也不知道如何适应
企业业务定义和层次的变化。企业信息化基础是数据基础，如果企业的业务系统没有和BI系统一起改善，一起发展，势必会拖累整个IT信息化。企业计划系
统，是基于数据仓库，但和传统BI不同的系统，它是人们主观地通过企业历史状况结合公司战略，形成的计划，比如公司A分公司A品牌去年销售1个亿，那么
结合公司策略，相关部门计划今年销售1.2个亿。最后持续改善的BI策略，这里就不多说了。
追求一个持续改善的BI模型，这点可以体现在第四个层面，可以借鉴成功的管理方案和分析技术，在该层面可以做到更好，不断提高。但前面三个层面呢？不重
要，没必要？
再则，多次谈到过，网站文章和书中的DW技术，都是人家高度总结的理论，一般多年前就形成了。像Inmon的DW2.0, 这个理论一出来，我就结合以
前做过的一个项目，发现他说的这些方面，那个项目已经做到了大部分。说明这个理论并不是完全的创新，而是很多实践和以往理论的新的高度的提升。再说
Kimball书中提到的理论，我想很多做DW的都有这个感觉，这个东西说得很好，但是具体怎么一步一步做，还是觉得很有差距。其实在细节上，他们咨询
的项目要比书中细致得多，考虑更全面，只是大方向确实和书中一致。如果仅仅是了解过熟读过这些理论，那么离数据仓库的技术真理，还差得很远。
最后，我觉得很奇怪，楼主把数据仓库架构和“持续改善管理文化”比较，咋不把云计算和“持续改善管理文化”比较呢？一个是对技术的归纳，一个是对管理的
归纳，能这样比较，很是佩服。
我多次说了，我说的DW架构和相关技术和楼主说的BI持续改善理念一点都不矛盾，但不知道为何楼主非要把BI持续改善理念涵盖了所有方面，包括DW架构
和其他基础系统，难道他们之间水火不容？我一直认为，技术基础和BI分析管理理念同样重要，并非任何一方可以比另一方更为重要，并非只有持续的DW架构
可以说是优秀的BI，也并非只有持续改善的BI理念就是优秀的BI。
在所有公司里，几乎都是各方面的牛人负责其中一个方面，由IT中高层来负责战略，我在公司里虽然各方面BI都做过，但自认在BI分析上不足，基础系统
（包括计划系统）更是不敢说熟悉精通，那么我就认认真真做好DW这块，做好他们之间的桥梁和技术支持即可。如果只是单方面考虑整个大体系，势必导致BI
整体不平衡和缺乏真正的长久持续性。
听百家讲坛里于丹说，大概意思是中庸之道的核心思想并不是什么事情我都选择折中，而是达到一种众观各个方面，择其（各方面）优势，去其（各方面）劣势，
成为更为合理的综合都考虑到更好的方案。
通其中一个方向，达到DW架构师或者BI分析专家。
不知道楼主算精通哪一个方向呢？不过看起来精通BI方面多点，数据仓库方面在广度方面我觉得也足够了，但光是靠那么些理论和见识过的项目就下结论，是否
显得偏颇？
持续改善的BI系统是每一个派系每一个BI公司和个人都在追求的，并非仅仅是一个概念或者理论，通过一个模型来解决，目前还看不到有这个迹象和可能。就
我的经历来看，持续改善的BI系统应该是合理的数据仓库架构+企业信息化基础的不断完善+不断有新的计划、预测系统结合真实的数据进行企业某些方面的战
略（上层人员执行）、策略（中低层人员执行）调整（非历史的真实的数据）+持续改善的BI分析策略和方案，共4部分组成。
数据仓库架构是基础，它直接导致系统是否有高延续性、高稳定性和高扩展性，否则计划、预测数据如何和历史数据结合起来存储你都不清楚，也不知道如何适应
企业业务定义和层次的变化。企业信息化基础是数据基础，如果企业的业务系统没有和BI系统一起改善，一起发展，势必会拖累整个IT信息化。企业计划系
统，是基于数据仓库，但和传统BI不同的系统，它是人们主观地通过企业历史状况结合公司战略，形成的计划，比如公司A分公司A品牌去年销售1个亿，那么
结合公司策略，相关部门计划今年销售1.2个亿。最后持续改善的BI策略，这里就不多说了。
追求一个持续改善的BI模型，这点可以体现在第四个层面，可以借鉴成功的管理方案和分析技术，在该层面可以做到更好，不断提高。但前面三个层面呢？不重
要，没必要？
再则，多次谈到过，网站文章和书中的DW技术，都是人家高度总结的理论，一般多年前就形成了。像Inmon的DW2.0, 这个理论一出来，我就结合以
前做过的一个项目，发现他说的这些方面，那个项目已经做到了大部分。说明这个理论并不是完全的创新，而是很多实践和以往理论的新的高度的提升。再说
Kimball书中提到的理论，我想很多做DW的都有这个感觉，这个东西说得很好，但是具体怎么一步一步做，还是觉得很有差距。其实在细节上，他们咨询
的项目要比书中细致得多，考虑更全面，只是大方向确实和书中一致。如果仅仅是了解过熟读过这些理论，那么离数据仓库的技术真理，还差得很远。
最后，我觉得很奇怪，楼主把数据仓库架构和“持续改善管理文化”比较，咋不把云计算和“持续改善管理文化”比较呢？一个是对技术的归纳，一个是对管理的
归纳，能这样比较，很是佩服。
我多次说了，我说的DW架构和相关技术和楼主说的BI持续改善理念一点都不矛盾，但不知道为何楼主非要把BI持续改善理念涵盖了所有方面，包括DW架构
和其他基础系统，难道他们之间水火不容？我一直认为，技术基础和BI分析管理理念同样重要，并非任何一方可以比另一方更为重要，并非只有持续的DW架构
可以说是优秀的BI，也并非只有持续改善的BI理念就是优秀的BI。
在所有公司里，几乎都是各方面的牛人负责其中一个方面，由IT中高层来负责战略，我在公司里虽然各方面BI都做过，但自认在BI分析上不足，基础系统
（包括计划系统）更是不敢说熟悉精通，那么我就认认真真做好DW这块，做好他们之间的桥梁和技术支持即可。如果只是单方面考虑整个大体系，势必导致BI
整体不平衡和缺乏真正的长久持续性。
听百家讲坛里于丹说，大概意思是中庸之道的核心思想并不是什么事情我都选择折中，而是达到一种众观各个方面，择其（各方面）优势，去其（各方面）劣势，
成为更为合理的综合都考虑到更好的方案。
interstage
May 11, 2008, 7:36:32 AM5/11/08
to ttnn BI 观点
科层式的组织架构通过"持续改善"管理机制(当然这个机制在中国企业还处于刚刚兴起,远不到大规模使用)走到了扁平式的组织架构.云计算是为了适合扁平
式的组织架构的新技术,目前还处于技术概念期间,远没到技术成熟期和大规模使用阶段.所以在中国去总结云计算和"持续改善"管理机制,太搞笑了,只能总
结商业智能技术(因为这个技术是最容易结合企业管理文化)和"持续改善"管理机制,形成适合中国企业的BI模型.连这点都不明白,真是不知道怎么想
的.
"就 我的经历来看，持续改善的BI系统应该是合理的数据仓库架构+企业信息化基础的不断完善+不断有新的计划、预测系统结合真实的数据进行企业某些方
系统总结起来了,太搞笑了, 所以,有句话说的好"无知者无畏",我是不是可以这样理解"无畏者无知"
BIDW从一个方向入手,我难道不知道,你仔细看看我的经理,从对迷信DW架构的BI项目实施效果的迷茫,到一个偶然的机会突然发现报表入手来展开
CDW(多维模型)架构,从对BI项目维护困难的迷茫,到从"持续改善"管理理论学习后再想到应该让IT部门和业务部门对BI运营的分解,从而引导"管
理视点"技术和方法来实现,那一个不是从一步一步的方向中走来,走完这些后,我利用这个成功了5个BI项目后,我想把这个经验和技术总结成"持续改
善"的BI模型,难道你觉得不妥吗,难道你可以总结出所谓"混合模型",就不允许我总结吗. 我的路程至少比你单从技术层面去深入,我认为至少比你深刻
的多.
式的组织架构的新技术,目前还处于技术概念期间,远没到技术成熟期和大规模使用阶段.所以在中国去总结云计算和"持续改善"管理机制,太搞笑了,只能总
结商业智能技术(因为这个技术是最容易结合企业管理文化)和"持续改善"管理机制,形成适合中国企业的BI模型.连这点都不明白,真是不知道怎么想
的.
"就 我的经历来看，持续改善的BI系统应该是合理的数据仓库架构+企业信息化基础的不断完善+不断有新的计划、预测系统结合真实的数据进行企业某些方
面的战
略（上层人员执行）、策略（中低层人员执行）调整（非历史的真实的数据）+持续改善的BI分析策略和方案，共4部分组成。"
呵呵,,你连"持续改善"的理论定义都不知道,它什么如何产生的,如何被定义,包含哪些,在哪些企业被使用了,就看"持续改善"四个字总可以和你的BI
略（上层人员执行）、策略（中低层人员执行）调整（非历史的真实的数据）+持续改善的BI分析策略和方案，共4部分组成。"
系统总结起来了,太搞笑了, 所以,有句话说的好"无知者无畏",我是不是可以这样理解"无畏者无知"
BIDW从一个方向入手,我难道不知道,你仔细看看我的经理,从对迷信DW架构的BI项目实施效果的迷茫,到一个偶然的机会突然发现报表入手来展开
CDW(多维模型)架构,从对BI项目维护困难的迷茫,到从"持续改善"管理理论学习后再想到应该让IT部门和业务部门对BI运营的分解,从而引导"管
理视点"技术和方法来实现,那一个不是从一步一步的方向中走来,走完这些后,我利用这个成功了5个BI项目后,我想把这个经验和技术总结成"持续改
善"的BI模型,难道你觉得不妥吗,难道你可以总结出所谓"混合模型",就不允许我总结吗. 我的路程至少比你单从技术层面去深入,我认为至少比你深刻
的多.
innovate511
May 11, 2008, 8:01:10 AM5/11/08
to ttnn BI 观点
话不投机半句多，我不是迷恋DW技术，而是我专注于这块，我不象有的人专注某个方向，却对所有方面都指手画脚，就象一个全能专家。我只知道业界高端项目
是这么做的，DW是其中一部分，BI分析也仅仅是其中一部分。至于谁在不知者无畏，让大家自己看吧。
最后恭维地说一句，您只是其中BI分析这块算是较为精通和熟悉，请不要再对自己不够精通和熟悉的地方乱发观点了。而且我也说过，我写的东西是给原因从中
获得启发去改善DW的人们看的，不是给老古板或者假内行看的。
如果非要说什么什么的，请不要老说BI持续改善方案，就可以覆盖其他重要部分。而且话说回来，是你在胡乱否定我的观点，而非我在挑衅你的观点，我非常认
可BI持续改善方案是企业BI系统很重要的一部分，但不是全部。而你却一再说DW架构忽悠什么的，貌似BI持续性改善方案已经含盖所有部分了，DW架构
可以很简单，符合基本理论就行，模型只要符合业界规范就行？
为什么所有TTNN的朋友都不认可你的态度？你可以看那个帖子，因为大家都知道我没有否定你的观点，而且我觉得那是BI中非常重要的部分，只是你太轻视
DW架构和相关技术，觉得这些都已经很成熟了，拿来用即可，最重要的就是搞好BI持续改善方案，其他都不重要了。于是才在每个我的DW帖子里都提到了类
似讽刺、挖苦和质问的回贴。
我不希望和谁做无谓的争吵，你在一个帖子中问我的问题，我已经认真地全部地回答了。如果非要拿一个和具体技术不那么相关的思想和我的技术帖子叫劲，我只
能拒绝回答，纯粹是牛头不对马嘴，还把持续管理的东西和数据仓库架构比较，一个是纯企业、业务管理方面，一个是技术方面，居然也能比较，不知道其他
BIer会怎么看。
奉劝看贴的朋友，注意“中庸之道”----- 从多个角度，多个项目、理论，去从不同角度总结优秀的观点、理念和经验技术，抛弃片面、不健全的那部
分。
> > 成为更为合理的综合都考虑到更好的方案。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
是这么做的，DW是其中一部分，BI分析也仅仅是其中一部分。至于谁在不知者无畏，让大家自己看吧。
最后恭维地说一句，您只是其中BI分析这块算是较为精通和熟悉，请不要再对自己不够精通和熟悉的地方乱发观点了。而且我也说过，我写的东西是给原因从中
获得启发去改善DW的人们看的，不是给老古板或者假内行看的。
如果非要说什么什么的，请不要老说BI持续改善方案，就可以覆盖其他重要部分。而且话说回来，是你在胡乱否定我的观点，而非我在挑衅你的观点，我非常认
可BI持续改善方案是企业BI系统很重要的一部分，但不是全部。而你却一再说DW架构忽悠什么的，貌似BI持续性改善方案已经含盖所有部分了，DW架构
可以很简单，符合基本理论就行，模型只要符合业界规范就行？
为什么所有TTNN的朋友都不认可你的态度？你可以看那个帖子，因为大家都知道我没有否定你的观点，而且我觉得那是BI中非常重要的部分，只是你太轻视
DW架构和相关技术，觉得这些都已经很成熟了，拿来用即可，最重要的就是搞好BI持续改善方案，其他都不重要了。于是才在每个我的DW帖子里都提到了类
似讽刺、挖苦和质问的回贴。
我不希望和谁做无谓的争吵，你在一个帖子中问我的问题，我已经认真地全部地回答了。如果非要拿一个和具体技术不那么相关的思想和我的技术帖子叫劲，我只
能拒绝回答，纯粹是牛头不对马嘴，还把持续管理的东西和数据仓库架构比较，一个是纯企业、业务管理方面，一个是技术方面，居然也能比较，不知道其他
BIer会怎么看。
奉劝看贴的朋友，注意“中庸之道”----- 从多个角度，多个项目、理论，去从不同角度总结优秀的观点、理念和经验技术，抛弃片面、不健全的那部
分。
>
> - 显示引用的文字 -
interstage
May 11, 2008, 9:56:52 AM5/11/08
to ttnn BI 观点
"为什么所有TTNN的朋友都不认可你的态度？"你怎么知道所有TTNN的朋友不认可我,都认可你,你调查了吗,相反很多TTNN的朋友昨天在MSN上
和我说,原来这个号称牛人的人提出的所谓什么"混合架构"终于在interstage的盘问下承认不是原创,是推广国外的经验,只不过加了自己所谓的什
么经验,真是没见过这么XXX的人,一直以为他牛比烘烘的原创, 呵呵!!
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
和我说,原来这个号称牛人的人提出的所谓什么"混合架构"终于在interstage的盘问下承认不是原创,是推广国外的经验,只不过加了自己所谓的什
么经验,真是没见过这么XXX的人,一直以为他牛比烘烘的原创, 呵呵!!
>
> - 显示引用的文字 -
interstage
May 11, 2008, 10:04:29 AM5/11/08
to ttnn BI 观点
持续管理的东西为什么不能数据仓库架构,你自己也承认架构也是包含管理方法(你自己去找前几天的帖子看),持续管理是一个管理理论,所谓管理就告诉企业
的人员应该遵守的工作方式和行为准则,难道数据仓库架构不涉及到人与机器的交互,人与人的交互,机器和机器的交互这3样交互层面,这3这个交互层面难道
可以不遵守企业所规定的行为方式,你以为是研究所的基础理论呀,不是应用理论,太搞笑,连基本道理都不懂,还在搞所谓架构研究,怪不得被TTNN的说是
XXX的人,我都不好意思提XXX是什么词了.
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
的人员应该遵守的工作方式和行为准则,难道数据仓库架构不涉及到人与机器的交互,人与人的交互,机器和机器的交互这3样交互层面,这3这个交互层面难道
可以不遵守企业所规定的行为方式,你以为是研究所的基础理论呀,不是应用理论,太搞笑,连基本道理都不懂,还在搞所谓架构研究,怪不得被TTNN的说是
XXX的人,我都不好意思提XXX是什么词了.
>
> - 显示引用的文字 -
innovate511
May 11, 2008, 11:13:44 AM5/11/08
to ttnn BI 观点
看看什么态度吧，找些不相干的话题打岔，对牛弹琴再多也无用，不过真是长见识了。
我对些客观存在的东西有新的体会和讲解难道不是原创么，这个混合架构也没有谁提出相关理论，只是实践中经常用到，而虚拟化架构逐步落实不是我的原创么？
怎么TTNN会有这么二的人，唉，不浪费时间了，还是多花点时间休息也比回无聊贴强。
如果有任何相关专业的技术讨论和问题再来回贴，包括阁下的问题和讨论。我也会继续发相关的技术帖子，至于某些人的无聊讽刺，我不会再回答。
我这人对事不对人，不想有的人会对人，能享受阁下每帖必讥讽的人也只有在下，而讥讽在下帖子的也只有阁下吧，真是幸会幸会。
我对些客观存在的东西有新的体会和讲解难道不是原创么，这个混合架构也没有谁提出相关理论，只是实践中经常用到，而虚拟化架构逐步落实不是我的原创么？
怎么TTNN会有这么二的人，唉，不浪费时间了，还是多花点时间休息也比回无聊贴强。
如果有任何相关专业的技术讨论和问题再来回贴，包括阁下的问题和讨论。我也会继续发相关的技术帖子，至于某些人的无聊讽刺，我不会再回答。
我这人对事不对人，不想有的人会对人，能享受阁下每帖必讥讽的人也只有在下，而讥讽在下帖子的也只有阁下吧，真是幸会幸会。
innovate511
May 11, 2008, 11:21:28 AM5/11/08
to ttnn BI 观点
好像凡是有关持续改善的系统、技术都得印上XX标示、XX原创似的，这个词语本身又不是什么专利，别人就不能说了？
如果要说持续改善的思想，哪个系统不是呢？上到整个社会的发展和管理，要和谐嘛，下到环保技术、软件技术、绿色产品的生产等等，难道非得说明应用了某某
管理理论？
算了，不继续这种不相关的回帖了，又浪费了我2分钟时间。
其实关于我对DW架构的本质的理解一贴，很多不相关帖子我都没去看，也没必要去看，不看都能猜到什么内容。只是昨天还是忍不住看了这个帖子，发现又把矛
头指向了我，真是幸会，劳你费心了。
如果要说持续改善的思想，哪个系统不是呢？上到整个社会的发展和管理，要和谐嘛，下到环保技术、软件技术、绿色产品的生产等等，难道非得说明应用了某某
管理理论？
算了，不继续这种不相关的回帖了，又浪费了我2分钟时间。
其实关于我对DW架构的本质的理解一贴，很多不相关帖子我都没去看，也没必要去看，不看都能猜到什么内容。只是昨天还是忍不住看了这个帖子，发现又把矛
头指向了我，真是幸会，劳你费心了。
innovate511
May 11, 2008, 11:36:40 AM5/11/08
to ttnn BI 观点
既然你指出了技术问题，我就回答这个帖子。
至于持续管理的思想，我一直在认同，只是某些人瞎着眼睛老是否定，只是我每出技术帖，某些人必会找茬。你提出的问题，我已经解答了，我还算有耐心去浪费
时间去回帖（因为可能某些人根本不能体会）。
“可以不遵守企业所规定的行为方式”，可笑，这个方法已经多个500强企业使用过，我自己也实践过3个行业的项目，设计过2个行业，我现在在规划和主设
计并通过公司一致认同，非常符合企业规定的行为方式，不仅仅解决了长远架构问题，还降低了公司了先期投资成本，可以看到效果后再继续投资升级。阁下失望
了吧？
至于说“你以为是研究所的基础理论呀,不是应用理论”，这更荒谬，这个仅仅是我的总结，通过多个项目总结而成。正如阁下总结的BI持续改善一样，只是阁
下是管理角度总结，我是从技术角度总结，可谓是井水不犯河水，但咄咄逼人的气势，恐怕是还无法不忘记1年多以前我在一个帖子无意中让你很没面子罢了。
“怪不得被TTNN的说是
> XXX的人,我都不好意思提XXX是什么词了.”TTNN除了阁下，还会有谁那么无聊讥讽我呢？我又没得罪他们。
本来这种帖子很没水平，要讥讽人也要找点靠谱的吧，以后这种帖子我也少回为好。正如Qing兄说的，每次必然会引起很多同行观战，我觉得他们就像看猴子
打假一样去看稀奇，很无聊。我可不想这么无聊，如果阁下实在想引起别人的注意，请自便，这种豪无专业水平的讥讽帖子，我不会每帖都看，每帖都回复阁下的
挑衅。
On 5月11日, 下午10时04分, interstage <buer0...@gmail.com> wrote:
> 持续管理的东西为什么不能数据仓库架构,你自己也承认架构也是包含管理方法(你自己去找前几天的帖子看),持续管理是一个管理理论,所谓管理就告诉企业
> 的人员应该遵守的工作方式和行为准则,难道数据仓库架构不涉及到人与机器的交互,人与人的交互,机器和机器的交互这3样交互层面,这3这个交互层面难道
> 可以不遵守企业所规定的行为方式,你以为是研究所的基础理论呀,不是应用理论,太搞笑,连基本道理都不懂,还在搞所谓架构研究,怪不得被TTNN的说是
> XXX的人,我都不好意思提XXX是什么词了.
>
至于持续管理的思想，我一直在认同，只是某些人瞎着眼睛老是否定，只是我每出技术帖，某些人必会找茬。你提出的问题，我已经解答了，我还算有耐心去浪费
时间去回帖（因为可能某些人根本不能体会）。
“可以不遵守企业所规定的行为方式”，可笑，这个方法已经多个500强企业使用过，我自己也实践过3个行业的项目，设计过2个行业，我现在在规划和主设
计并通过公司一致认同，非常符合企业规定的行为方式，不仅仅解决了长远架构问题，还降低了公司了先期投资成本，可以看到效果后再继续投资升级。阁下失望
了吧？
至于说“你以为是研究所的基础理论呀,不是应用理论”，这更荒谬，这个仅仅是我的总结，通过多个项目总结而成。正如阁下总结的BI持续改善一样，只是阁
下是管理角度总结，我是从技术角度总结，可谓是井水不犯河水，但咄咄逼人的气势，恐怕是还无法不忘记1年多以前我在一个帖子无意中让你很没面子罢了。
“怪不得被TTNN的说是
> XXX的人,我都不好意思提XXX是什么词了.”TTNN除了阁下，还会有谁那么无聊讥讽我呢？我又没得罪他们。
本来这种帖子很没水平，要讥讽人也要找点靠谱的吧，以后这种帖子我也少回为好。正如Qing兄说的，每次必然会引起很多同行观战，我觉得他们就像看猴子
打假一样去看稀奇，很无聊。我可不想这么无聊，如果阁下实在想引起别人的注意，请自便，这种豪无专业水平的讥讽帖子，我不会每帖都看，每帖都回复阁下的
挑衅。
On 5月11日, 下午10时04分, interstage <buer0...@gmail.com> wrote:
> 持续管理的东西为什么不能数据仓库架构,你自己也承认架构也是包含管理方法(你自己去找前几天的帖子看),持续管理是一个管理理论,所谓管理就告诉企业
> 的人员应该遵守的工作方式和行为准则,难道数据仓库架构不涉及到人与机器的交互,人与人的交互,机器和机器的交互这3样交互层面,这3这个交互层面难道
> 可以不遵守企业所规定的行为方式,你以为是研究所的基础理论呀,不是应用理论,太搞笑,连基本道理都不懂,还在搞所谓架构研究,怪不得被TTNN的说是
> XXX的人,我都不好意思提XXX是什么词了.
>
interstage
May 11, 2008, 9:58:14 PM5/11/08
to ttnn BI 观点
"如果要说持续改善的思想，哪个系统不是呢?"就凭这句话， 看来你真的对＂持续改善＂是很无知，中国企业的系统基本上都是不遵守＂持续改善＂的管理思
想，所以中国很多企业开始学习＂持续改善＂管理理论，准备引入到自己企业中，所以我说你对业务管理很无知，以为中国企业的系统基于的管理理论很成功．２
位大师的架构符合的管理理论是＂创新＂－＂维护＂的理论，所以也需要修正，但绝不是向你对DW架构的理解方向修正. 至于你说"TTNN的人都反对
我","都支持你",我告诉你,你的自我感觉太好,我举TTNN的朋友在MSN和我交流的例子,就是告诉你不要太自我感觉太好.你以为我对人不对事情,
你把自己看的太高了,如果"我对你人身攻击"对我有什么好处,所以我一直感觉你心态有问题,对你的架构表示疑问和盘问,表示有很严重的不可操作性,就以
为对你人身进行了攻击,然后就说"TTNN都支持你",太敏感了吧,这么敏感的心态还搞创新,呵呵,我真的很怀疑这样的创新成果.
想，所以中国很多企业开始学习＂持续改善＂管理理论，准备引入到自己企业中，所以我说你对业务管理很无知，以为中国企业的系统基于的管理理论很成功．２
位大师的架构符合的管理理论是＂创新＂－＂维护＂的理论，所以也需要修正，但绝不是向你对DW架构的理解方向修正. 至于你说"TTNN的人都反对
我","都支持你",我告诉你,你的自我感觉太好,我举TTNN的朋友在MSN和我交流的例子,就是告诉你不要太自我感觉太好.你以为我对人不对事情,
你把自己看的太高了,如果"我对你人身攻击"对我有什么好处,所以我一直感觉你心态有问题,对你的架构表示疑问和盘问,表示有很严重的不可操作性,就以
为对你人身进行了攻击,然后就说"TTNN都支持你",太敏感了吧,这么敏感的心态还搞创新,呵呵,我真的很怀疑这样的创新成果.
Reply all
Reply to author
Forward
0 new messages