讨论数据仓库项目中远期规划
5 views
Skip to first unread message
innovate511
Mar 19, 2008, 9:34:04 AM3/19/08
to ttnn BI 观点
首先谈数据仓库项目规划需要关注的重要点。抛砖引玉，逐步讨论。
目前除了甲方自己外，很少有乙方去做全方位的整体规划。乙方一般都是从客户需求出发，也就是说甲方想到要什么，乙方才给出对应的具体方案来。这里主要和
甲方朋友以及外包给乙方做中长远规划的乙方朋友一起交流高质量且可行性高的规划，规划使用周期为5-10年。
首先分析未来项目中可能带来的挑战，可参考同行业或者类似龙头企业的情况。大概挑战如下：
1。数据量预测。可以参考公司现有数据量和未来公司业务发展规划，大概估计未来几年数据量会是现在的几倍。
2。大主题方向扩展。大型公司一般在后来都会有10个以上的主题，意味着至少10个以上的数据集市，如何统一又满足个性化的整合是一大挑战。
3。业务预测。可以参考公司发展规划中，产品大类规划、区域扩展规划、人力发展规划以及市场占有率规划等等。而公司高速发展期间，一般会有新业务或行业
发展、业务整合、部门调整、大区调整、品牌战略调整等。
4。系统功能变化预测。随着信息化的推进，数据仓库不再会是孤立的系统，需要和其他系统进行互相帮助和整合。
5。BI需求变化预测。众所周知，BI需求一般开始就是报表，而之后取得客户信任后，才会逐步推行更多BI应用。所以规划中要满足全BI应用，如固定报
表、查询、多维报表/分析/查询、数据挖掘，近实时BI等等。
那么规划就应该主要围绕这些主要问题和矛盾去“多维思考”。
目前除了甲方自己外，很少有乙方去做全方位的整体规划。乙方一般都是从客户需求出发，也就是说甲方想到要什么，乙方才给出对应的具体方案来。这里主要和
甲方朋友以及外包给乙方做中长远规划的乙方朋友一起交流高质量且可行性高的规划，规划使用周期为5-10年。
首先分析未来项目中可能带来的挑战，可参考同行业或者类似龙头企业的情况。大概挑战如下：
1。数据量预测。可以参考公司现有数据量和未来公司业务发展规划，大概估计未来几年数据量会是现在的几倍。
2。大主题方向扩展。大型公司一般在后来都会有10个以上的主题，意味着至少10个以上的数据集市，如何统一又满足个性化的整合是一大挑战。
3。业务预测。可以参考公司发展规划中，产品大类规划、区域扩展规划、人力发展规划以及市场占有率规划等等。而公司高速发展期间，一般会有新业务或行业
发展、业务整合、部门调整、大区调整、品牌战略调整等。
4。系统功能变化预测。随着信息化的推进，数据仓库不再会是孤立的系统，需要和其他系统进行互相帮助和整合。
5。BI需求变化预测。众所周知，BI需求一般开始就是报表，而之后取得客户信任后，才会逐步推行更多BI应用。所以规划中要满足全BI应用，如固定报
表、查询、多维报表/分析/查询、数据挖掘，近实时BI等等。
那么规划就应该主要围绕这些主要问题和矛盾去“多维思考”。
Qing
Mar 20, 2008, 12:16:14 AM3/20/08
to tt...@googlegroups.com
也许还有一个重要的事情需要考虑，就是未来的5-10年，你们的业务流程会有怎样的改变。
是有一个统一的报表门户？大家不用再为口径不一致而且数据不一致的指标发愁？大家每天都可以看到自己的关键绩效指标的进展？策略部门，有简洁的分析工具，在产品设计、推广方面都可以轻松搞定，甚至是向导式地搞定？业务上的重大问题，都有专用的分析模块，辅助优化解决？一线部门，在面对客户的时候，能够迅速掌握丰富的客户信息，并且能够得到产品服务建议，更好服务客户？
做一些这样的想象，然后跟高层达成一致意见——我们要实现那个美景。
golde...@163.com
Mar 20, 2008, 1:20:08 AM3/20/08
to ttnn BI 观点
抛开企业的中远期发展战略而谈数据仓库的中远期规划是不现实的，也是没有出发点、立足点的。业务发展趋势，例如企业的拆分、并购、行业监管规则、法律法
规变化等，都对企业影响巨大。例如保险企业，可能因为获得执照，而扩大了业务线；可能因为放开混业经营而与银行合营重组等；联想并购IBM PC业务、
塔塔兼并虎豹等等；这些都可能会大大改变企业数据仓库的格局。哪怕只在较为明确的业务范畴内，企业的管理上也会有变化，例如零售企业开始扩张时期可能是
全面铺点，业绩迅速上升；之后开始优化调整，逐渐扁平化管理，模式趋于稳定等；后又逐渐多元化经营，增加了一些关联的上下游行业业务；后准备上市融资－
整体上市或局部优良资产上市。。在每个点上去规划数据仓库，都可能是不同的。当然，也许发生这种变化时IT重新构建的成本只是整体代价的一小部分，因此
可以放在考虑之外。
在企业的中远期发展战略已经明确之下，也不能跨过IT的中远期规划直接作数据仓库的中远期规划。因为数据仓库只是IT的整体架构的一部分，数据仓库在
IT环境中是怎样的定位，才能决定数据仓库规划的基调。在应用层面上，原业务功能与数据仓库数据应用功能重叠部分需要明确分工方式，否则部门级的小集市
一个个单独做的不亦乐乎，数据仓库成了空库。
在这些都明确的情况下，数据仓库中长期规划就可以动手搞了。仍要基于目标业务的一些假定（例如对电器零售商，五年十年后，现有三级管理模式未来演化为两
级，店门达到500个，市场占有率达到30%），那么数据仓库能力也是一个逐步增强、架构逐渐扩展、数据逐步集中整合的过程。这时候才考虑数据量的增
长、硬件基础平台的扩充、与一些业务系统功能的整合等。BI的分析功能是一组功能集，不必强调高低次序－报表在先/分析次之/最后上挖掘，可能是先拿数
据挖掘功能手段迅速的抢占制高点、使业务部门的拜服，而后才踏踏实实做报表也不一定。
中长期规划
> 那么规划就应该主要围绕这些主要问题和矛盾去"多维思考"。
规变化等，都对企业影响巨大。例如保险企业，可能因为获得执照，而扩大了业务线；可能因为放开混业经营而与银行合营重组等；联想并购IBM PC业务、
塔塔兼并虎豹等等；这些都可能会大大改变企业数据仓库的格局。哪怕只在较为明确的业务范畴内，企业的管理上也会有变化，例如零售企业开始扩张时期可能是
全面铺点，业绩迅速上升；之后开始优化调整，逐渐扁平化管理，模式趋于稳定等；后又逐渐多元化经营，增加了一些关联的上下游行业业务；后准备上市融资－
整体上市或局部优良资产上市。。在每个点上去规划数据仓库，都可能是不同的。当然，也许发生这种变化时IT重新构建的成本只是整体代价的一小部分，因此
可以放在考虑之外。
在企业的中远期发展战略已经明确之下，也不能跨过IT的中远期规划直接作数据仓库的中远期规划。因为数据仓库只是IT的整体架构的一部分，数据仓库在
IT环境中是怎样的定位，才能决定数据仓库规划的基调。在应用层面上，原业务功能与数据仓库数据应用功能重叠部分需要明确分工方式，否则部门级的小集市
一个个单独做的不亦乐乎，数据仓库成了空库。
在这些都明确的情况下，数据仓库中长期规划就可以动手搞了。仍要基于目标业务的一些假定（例如对电器零售商，五年十年后，现有三级管理模式未来演化为两
级，店门达到500个，市场占有率达到30%），那么数据仓库能力也是一个逐步增强、架构逐渐扩展、数据逐步集中整合的过程。这时候才考虑数据量的增
长、硬件基础平台的扩充、与一些业务系统功能的整合等。BI的分析功能是一组功能集，不必强调高低次序－报表在先/分析次之/最后上挖掘，可能是先拿数
据挖掘功能手段迅速的抢占制高点、使业务部门的拜服，而后才踏踏实实做报表也不一定。
中长期规划
Qing
Mar 21, 2008, 1:20:01 AM3/21/08
to tt...@googlegroups.com
这话在理。不过既然在这里讨论，当然先得假设发展战略是已经ok了的，或者至少有个谱的。当然，也许这个假设不成立，那我们就纯粹在这里扯淡也行。
不知道innovate所在什么行业。在电信行业里面，是流行这种规划的，有些做的很充足，请很多乙方一起参与，花上很长时间（多长时间我也不知道，相对而言）制作出宏伟蓝图。有的很潦草，期望能够在一周里面搞定。但也不用以为长时间做出来的规划就很好得到落实，能不能落实，那时执行的事情。但是否就此说，规划没什么用？那就不好说了。我想，规划和执行这是两码事，规划的时候当然要考虑企业执行力的因素，当如果考虑过多了，也会使规划失去想象力。
在上面列出的几点里面，有些是从业务角度考虑，比如需求变化、主要专题等，有些是从技术角度，比如数据量、功能变化等等，可以将这两部分分开，得以业务为头。如果规划仅仅是it部门自己折腾，恐怕到以后的执行也会成为大问题。
业务上的事情，恐怕变数不是谁说了算的。去预测它的变化有时候也真是捕风捉影，对此，我还是原来的观点，先去构思一下未来业务流程的变化，而不是具体的业务领域，这是第二步的事情。
技术上的规划，是想能有个强大的架构去满足这些不断变化的业务需求吧。我不知道去架构一个满足5年变化的架构是个什么样子，那应该是一个非常基础的，甚至是跟具体业务干系不大。而只是将业务抽象到几种类型，考虑几种变化。这个架构拥有一个包容企业中新增、变化的概念，有灵活的元数据，让数据管理员，让业务人员可以快捷、方便地访问数据。有稳固的质量保证机制，让数据的使用人员对他获得的东西感到放心。这点，应该业界有很多研究。问题是跟实践的结合需要经历不断失败。
以前中国电信搞了很宏伟的几年规划，不知道现在执行进展如何。如果有了解的，不妨说说。
zpdxi...@gmail.com
Mar 21, 2008, 2:22:42 AM3/21/08
to tt...@googlegroups.com
在业务放在第一位的前提下，业务人员要注重业务的归纳抽象、业务流程的优化、而不是等技术人员过来咨询这些，既然业务第一，那么业务用户要成为事情的主要推动者；技术人员应该精深自己的技术，要深入技术的精髓，即使使用产品，也应该真正去了解和去评测所用的产品，知道它能敢什么，不能干什么，应用的极限在哪里，
而不是把问题都交给厂方的人员来解决，自己只盯产品使用文档，这样面对业务人员的问题时自己都可能没有底气。
业务人员和技术人员就象企业这台机器的两条内存，如果建立良好的双通道机制，那这台机器的性能就大大提升了。
不过，现实和想象总是有差距的... ...
关键的一点还在于执行力上面 有句话叫预测未来的最好方法就是把它创造出来。
2008-03-21
发件人： Qing
发送时间： 2008-03-21 13:20:22
抄送：
主题： Re: 讨论数据仓库项目中远期规划
zpdxi...@gmail.com
Mar 21, 2008, 2:22:42 AM3/21/08
to tt...@googlegroups.com
在业务放在第一位的前提下，业务人员要注重业务的归纳抽象、业务流程的优化、而不是等技术人员过来咨询这些，既然业务第一，那么业务用户要成为事情的主要推动者；技术人员应该精深自己的技术，要深入技术的精髓，即使使用产品，也应该真正去了解和去评测所用的产品，知道它能敢什么，不能干什么，应用的极限在哪里，
而不是把问题都交给厂方的人员来解决，自己只盯产品使用文档，这样面对业务人员的问题时自己都可能没有底气。
业务人员和技术人员就象企业这台机器的两条内存，如果建立良好的双通道机制，那这台机器的性能就大大提升了。
不过，现实和想象总是有差距的... ...
关键的一点还在于执行力上面 有句话叫预测未来的最好方法就是把它创造出来。
2008-03-21
发件人： Qing
发送时间： 2008-03-21 13:20:22
抄送：
主题： Re: 讨论数据仓库项目中远期规划
innovate511
Mar 21, 2008, 10:50:12 AM3/21/08
to ttnn BI 观点
可能大家有个误解，就是好象规划就是以纯技术为中心，不关注业务的变化，业务结构的变化。这里我要澄清以下几点：
1。规划是以DWBI项目经验、行业经验和DWBI理论为中心，而非技术为中心，简单地针对数据量和技术功能。
2。DWBI技术，也并非象传统软件那样，技术仅仅包括基础平台和软件、代码本身，象传统数据模型、行业模型、面对业务/结构变化的思想，都是技术。
3。业务的重要性，并非就是要脱离基础平台或者方法论去专门研究业务和业务变化、趋势，业务只有和DWBI先进成熟的技术（这里说的技术范畴）结合，才
能发挥到及至，让业务部门充分享受BI的快乐。而不是他们想得到，但经常得不到，或者看不到BI传说中力量。
所以我在公司规划中以以下几个视角去规划：
1. 逻辑架构规划（整体数据仓库逻辑）
2. 物理架构规划（基础平台以及数据仓库物理架构）
3. 数据架构（含数据流架构、数据管理架构、数据安全架构）
4. ETL架构（包括ETL技术架构和ETL流程架构）
5. 业务数据架构（处理业务变化、组织机构变化和个性化分析需求的思想架构）
这一周我完成了1、3、5架构体系，下周继续2、4
架构完成后，我会申请开始研发数据模型，包括通用的参考数据模型体系和控制数据模型，并完善已买的Oracle行业模型，现有的模型思想还凑合，只是很
多东西第一个主题还没用上，有的方面还做得不够。在通用模型方面，只需要和同事讨论，了解现有模型就行了，而业务模型，真的需要足够的业务讨论才能更好
得出。
1。规划是以DWBI项目经验、行业经验和DWBI理论为中心，而非技术为中心，简单地针对数据量和技术功能。
2。DWBI技术，也并非象传统软件那样，技术仅仅包括基础平台和软件、代码本身，象传统数据模型、行业模型、面对业务/结构变化的思想，都是技术。
3。业务的重要性，并非就是要脱离基础平台或者方法论去专门研究业务和业务变化、趋势，业务只有和DWBI先进成熟的技术（这里说的技术范畴）结合，才
能发挥到及至，让业务部门充分享受BI的快乐。而不是他们想得到，但经常得不到，或者看不到BI传说中力量。
所以我在公司规划中以以下几个视角去规划：
1. 逻辑架构规划（整体数据仓库逻辑）
2. 物理架构规划（基础平台以及数据仓库物理架构）
3. 数据架构（含数据流架构、数据管理架构、数据安全架构）
4. ETL架构（包括ETL技术架构和ETL流程架构）
5. 业务数据架构（处理业务变化、组织机构变化和个性化分析需求的思想架构）
这一周我完成了1、3、5架构体系，下周继续2、4
架构完成后，我会申请开始研发数据模型，包括通用的参考数据模型体系和控制数据模型，并完善已买的Oracle行业模型，现有的模型思想还凑合，只是很
多东西第一个主题还没用上，有的方面还做得不够。在通用模型方面，只需要和同事讨论，了解现有模型就行了，而业务模型，真的需要足够的业务讨论才能更好
得出。
interstage
Mar 21, 2008, 1:05:34 PM3/21/08
to ttnn BI 观点
哎,又在整这些没用的东西,中国民企目前业务模式平均1.5年变化一个方向,这是由于他们的环境决定的,他们成不了伟大的企业,如果他们没有一点国家背
景的话,一个成不了伟大企业的公司居然整5-10年的数据规划.除非老板有什么目的或者你忽悠了老板.不管什么情况,你不要当真(可能你就没把这事情当
真,只是在这里忽悠BIERS帮你出点方案的思路),只要搞个方案上去,磨洋工的实施,增加自己有数据规划能力的个人经验,在自己的简历上添上重重一笔
就可以.哎,所以我们的BIER就是这样,这把自己当成企业管理战略大师了,永远不会脚踏实地的做事情,连搞了数据项目规划也要和企业管理战略规划结合
在一起,简直就是神人.
景的话,一个成不了伟大企业的公司居然整5-10年的数据规划.除非老板有什么目的或者你忽悠了老板.不管什么情况,你不要当真(可能你就没把这事情当
真,只是在这里忽悠BIERS帮你出点方案的思路),只要搞个方案上去,磨洋工的实施,增加自己有数据规划能力的个人经验,在自己的简历上添上重重一笔
就可以.哎,所以我们的BIER就是这样,这把自己当成企业管理战略大师了,永远不会脚踏实地的做事情,连搞了数据项目规划也要和企业管理战略规划结合
在一起,简直就是神人.
innovate511
Mar 22, 2008, 10:20:36 AM3/22/08
to ttnn BI 观点
楼上的大哥，不懂数据仓库能不能先闭嘴，都不好意思说你了，你太专注业务BI了，要不Qing兄给这个痴迷于业务BI的前辈讲讲？而且你可能也没做过真
正规划好的，而且认真按照规划去循序渐进实施10年的大型DW（10多TB，数万最终用户，99年开始规划建设）吧？不知道当初人家规划的时候，是不是
有人在那里热潮冷风的。还好上述规划几点我都有积累，不然真被有的人笑话了。
不过做技术的，在网上到了这个份上，我不知道该说些什么。
> > 那么规划就应该主要围绕这些主要问题和矛盾去“多维思考”。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
正规划好的，而且认真按照规划去循序渐进实施10年的大型DW（10多TB，数万最终用户，99年开始规划建设）吧？不知道当初人家规划的时候，是不是
有人在那里热潮冷风的。还好上述规划几点我都有积累，不然真被有的人笑话了。
不过做技术的，在网上到了这个份上，我不知道该说些什么。
>
> - 显示引用的文字 -
innovate511
Mar 22, 2008, 10:24:33 AM3/22/08
to ttnn BI 观点
业务模型的变化，难道全是业务问题，如果不懂数据模型对业务变化，业务、组织结构变化
的支撑技术，最好不要乱发言，也许你没见识过，但不表示不存在。现在中国来的那些外企，都是卖产品为主的，产品精通我信，不过要说到整体方案专家，特别
包括后台数据仓库方面的，可能有限。
的支撑技术，最好不要乱发言，也许你没见识过，但不表示不存在。现在中国来的那些外企，都是卖产品为主的，产品精通我信，不过要说到整体方案专家，特别
包括后台数据仓库方面的，可能有限。
innovate511
Mar 22, 2008, 12:34:58 PM3/22/08
to ttnn BI 观点
逻辑架构规划，首先看看未来趋势，是否采用哪种架构。我个人觉得最好的方式是有ODS，有范式模型的EDW，也有客户化维度型数据仓库（CDW，由范式
到多维，采用统一维度建模思想），然后是数据集市。其中ODS需要有如下功能：数据清洗/准备、业务数据集成过渡（供业务系统数据集成过渡使用）、即时
BI数据源；
EDW主要功能还是在数据整合集成方面，但不直接给BI使用，中长远看，EDW是必须的，他不但可以最好地管理数据，管理历史数据，而且能保持最细的数
据，没有业务转换的数据，意味着哪怕维度模型有天翻地覆的变化，EDW也能做最好的支撑。有的项目EDW也支持最细节的复杂查询，我觉得这个要看情况去
理解具体需求了。
CDW也是必须的，BI分析不能没有维度模型，但多个主题的分析，要解决业务数据一致性、统一性，必须统一建模。它也需要有一定历史数据，来支撑分析，
但是更大的特点是，周期性特强，日、周、月、季、年，分别可有自己的周期汇总数据。
数据集市主要是为BI提供数据，由于BI分析的多样性，所以一般来说，数据集市的模型会比统一维度的还要详细许多，扩展许多，个性化分析需求的字段也需
要根据情况扩展。各种展现效率、安全管理、业务变化，都得有充分的设计。
至于如何满足更大更大数据量出现的挑战，如何满足业务的变化，如何满足业务组织结构的变化，如何满足BI分析的变化，得靠其他几个角度综合看了，下次再
来说说一些其他角度的观点。
到多维，采用统一维度建模思想），然后是数据集市。其中ODS需要有如下功能：数据清洗/准备、业务数据集成过渡（供业务系统数据集成过渡使用）、即时
BI数据源；
EDW主要功能还是在数据整合集成方面，但不直接给BI使用，中长远看，EDW是必须的，他不但可以最好地管理数据，管理历史数据，而且能保持最细的数
据，没有业务转换的数据，意味着哪怕维度模型有天翻地覆的变化，EDW也能做最好的支撑。有的项目EDW也支持最细节的复杂查询，我觉得这个要看情况去
理解具体需求了。
CDW也是必须的，BI分析不能没有维度模型，但多个主题的分析，要解决业务数据一致性、统一性，必须统一建模。它也需要有一定历史数据，来支撑分析，
但是更大的特点是，周期性特强，日、周、月、季、年，分别可有自己的周期汇总数据。
数据集市主要是为BI提供数据，由于BI分析的多样性，所以一般来说，数据集市的模型会比统一维度的还要详细许多，扩展许多，个性化分析需求的字段也需
要根据情况扩展。各种展现效率、安全管理、业务变化，都得有充分的设计。
至于如何满足更大更大数据量出现的挑战，如何满足业务的变化，如何满足业务组织结构的变化，如何满足BI分析的变化，得靠其他几个角度综合看了，下次再
来说说一些其他角度的观点。
innovate511
Mar 22, 2008, 12:40:45 PM3/22/08
to ttnn BI 观点
还有一点interstage 老兄，这是数据仓库规划，和企业战略管理有啥关系？不要尽搞些不靠谱的讽刺好不？
至于踏踏实实做事，我在项目总结那里写了很多细节的总结要素，被人说成是落后的流程，这个软件开发工程，和业务流程有个啥关系呢？搞些不靠普的东西就叫
踏踏实实了？开什么玩笑？
我这里的规划，心里早就有数了，相关资料和模型俱全，只是拿出来大家看看，是否有人也在做这个事情。如果心里没点谱就搞所谓的规划，那不是骗子是什么
呢？
至于踏踏实实做事，我在项目总结那里写了很多细节的总结要素，被人说成是落后的流程，这个软件开发工程，和业务流程有个啥关系呢？搞些不靠普的东西就叫
踏踏实实了？开什么玩笑？
我这里的规划，心里早就有数了，相关资料和模型俱全，只是拿出来大家看看，是否有人也在做这个事情。如果心里没点谱就搞所谓的规划，那不是骗子是什么
呢？
golde...@163.com
Mar 22, 2008, 8:12:15 PM3/22/08
to ttnn BI 观点
如果只作技术规划，那跟做一个《大型企业数据仓库前沿技术研究》的论文有什么区别？规划的目的是什么呢？或者说规划的内容谁会关心？领导层如何对这个规
划进行评价？因为看不懂，又没有什么决策点，只好说－－同志们工作辛苦了！
On Mar 21, 1:20 pm, Qing <happys...@gmail.com> wrote:
> 这话在理。不过既然在这里讨论，当然先得假设发展战略是已经ok了的，或者至少有个谱的。当然，也许这个假设不成立，那我们就纯粹在这里扯淡也行。
>
> 不知道innovate所在什么行业。在电信行业里面，是流行这种规划的，有些做的很充足，请很多乙方一起参与，花上很长时间（多长时间我也不知道，相对而言）-制作出宏伟蓝图。有的很潦草，期望能够在一周里面搞定。但也不用以为长时间做出来的规划就很好得到落实，能不能落实，那时执行的事情。但是否就此说，规划没什么-用？那就不好说了。我想，规划和执行这是两码事，规划的时候当然要考虑企业执行力的因素，当如果考虑过多了，也会使规划失去想象力。
>
> 在上面列出的几点里面，有些是从业务角度考虑，比如需求变化、主要专题等，有些是从技术角度，比如数据量、功能变化等等，可以将这两部分分开，得以业务为头。如-果规划仅仅是it部门自己折腾，恐怕到以后的执行也会成为大问题。
>
> 业务上的事情，恐怕变数不是谁说了算的。去预测它的变化有时候也真是捕风捉影，对此，我还是原来的观点，先去构思一下未来业务流程的变化，而不是具体的业务领域-，这是第二步的事情。
>
> 技术上的规划，是想能有个强大的架构去满足这些不断变化的业务需求吧。我不知道去架构一个满足5年变化的架构是个什么样子，那应该是一个非常基础的，甚至是跟具-体业务干系不大。而只是将业务抽象到几种类型，考虑几种变化。这个架构拥有一个包容企业中新增、变化的概念，有灵活的元数据，让数据管理员，让业务人员可以快捷-、方便地访问数据。有稳固的质量保证机制，让数据的使用人员对他获得的东西感到放心。这点，应该业界有很多研究。问题是跟实践的结合需要经历不断失败。
>
> 以前中国电信搞了很宏伟的几年规划，不知道现在执行进展如何。如果有了解的，不妨说说。
>
> 2008/3/20 <goldenfi...@163.com>:
>
>
>
> > 抛开企业的中远期发展战略而谈数据仓库的中远期规划是不现实的，...- Hide quoted text -
>
> - Show quoted text -
划进行评价？因为看不懂，又没有什么决策点，只好说－－同志们工作辛苦了！
On Mar 21, 1:20 pm, Qing <happys...@gmail.com> wrote:
> 这话在理。不过既然在这里讨论，当然先得假设发展战略是已经ok了的，或者至少有个谱的。当然，也许这个假设不成立，那我们就纯粹在这里扯淡也行。
>
>
> 在上面列出的几点里面，有些是从业务角度考虑，比如需求变化、主要专题等，有些是从技术角度，比如数据量、功能变化等等，可以将这两部分分开，得以业务为头。如-果规划仅仅是it部门自己折腾，恐怕到以后的执行也会成为大问题。
>
> 业务上的事情，恐怕变数不是谁说了算的。去预测它的变化有时候也真是捕风捉影，对此，我还是原来的观点，先去构思一下未来业务流程的变化，而不是具体的业务领域-，这是第二步的事情。
>
> 技术上的规划，是想能有个强大的架构去满足这些不断变化的业务需求吧。我不知道去架构一个满足5年变化的架构是个什么样子，那应该是一个非常基础的，甚至是跟具-体业务干系不大。而只是将业务抽象到几种类型，考虑几种变化。这个架构拥有一个包容企业中新增、变化的概念，有灵活的元数据，让数据管理员，让业务人员可以快捷-、方便地访问数据。有稳固的质量保证机制，让数据的使用人员对他获得的东西感到放心。这点，应该业界有很多研究。问题是跟实践的结合需要经历不断失败。
>
> 以前中国电信搞了很宏伟的几年规划，不知道现在执行进展如何。如果有了解的，不妨说说。
>
> 2008/3/20 <goldenfi...@163.com>:
>
>
>
> > 抛开企业的中远期发展战略而谈数据仓库的中远期规划是不现实的，...- Hide quoted text -
>
> - Show quoted text -
huangkan
Mar 22, 2008, 10:33:54 PM3/22/08
to tt...@googlegroups.com
"规划的事情很重要，持续的改进更重要"。数据仓库规划和企业战略发展方向规划还是有点关系的，比如，你的数据仓库建设的着手点可能不一样。另外，既然是数据仓库项目规划，我想，除了技术方面的东西外，是不是还要有些关于后续运营和治理的规划？既然提到要重视业务部门，那么和业务的互动以及业务推动数据仓库的流程方面就很重要了。只是一点建议啊。
innovate511
Mar 23, 2008, 2:30:08 AM3/23/08
to ttnn BI 观点
再次申明，这里的规划是方向上的规划，并非业务规划，更非战略规划。也难怪没人做这个事情，大家一般不是钻研业务分析和分析改进，就是研究项目中数据仓
库的具体问题，所谓不在其位不谋其职。
规划的中心思想是什么？中心思想就是确定架构扩展方向，数据扩展方向，模型改进方向，用已经规划过的，而且成功实施数年甚至10年以上的项目经验结合各
种技术和理论，规划面向未来发展的基础架构。如果没有那种成熟项目经验的规划，可能确实就是摸着石头过河，容易顾此失彼。
规划的最大好处是什么？目前接触到几家甲方的人员，他们的项目换过乙方，也换过方案，也重新梳理过模型，但是后来感觉项目投资和效果严重不成比例，项目
没连续性，重复投资大，移植成本过高，最终用户反应大。规划的最大好处就是项目延续性，整体性，用更合理的投资取得最大的成果。
规划在项目中的核心利益是什么？规划就是指名一个方向，从多个角度参考顶级成熟项目，指名项目发展方向。然后从现实角度出发，和各级领导一起讨论逐步推
进项目的详细计划，逐步完善数据仓库架构，如果没有规划，具体的一个个项目，就像无头的苍蝇，想到哪设计到哪，发现问题就去补一个问题，项目2年以后肯
定千种百孔，无法再延续下去，可能需要推翻再来。
如果说战略发展方向有关系的话，那么只有一点关系，就是企业高层想怎么去处理BI方面的事情，是上一个主题算一个主题，发现一个问题再补充一个问题，还
是从开始就制定出架构方向，然后一步步循序渐进地实施下去。
如果说像写书，我想未来写书也不是不可能，一直没时间写。不过既然在企业里做，规划仅仅是项目的前奏。在一个月内最终确定架构方向后，我已经把模型研
发、ETL优化纳入日程，为改善现有项目以及即将进行的新架构移植，并为下一个主题结合老主题做统一维度建模的第一个方案版本。一般理论书上不会说参考
模型和控制模型，但我会根据经验去研发适合公司的模型。因为这两种模型属于非业务主题模型，要高质量项目它们是必须的，如果要求不高，他们不是必须的，
或者没有成为体系，想到哪里设计那么一点点来补漏。
业务推动和数据仓库架构规划没有矛盾，数据仓库架构只是支撑整个系统的基础，业务变化和改进是另一个层面的事情。上面讲到的两个辅助模型，就是帮助处理
业务变化和改进的辅助体，这样主体模型才能更好地体现业务的变化甚至业务组织机构的变化和改进。
On 3月23日, 上午10时33分, huangkan <erichuangta...@gmail.com> wrote:
> "规划的事情很重要，持续的改进更重要"。数据仓库规划和企业战略发展方向规划还是有点关系的，比如，你的数据仓库建设的着手点可能不一样。另外，既然是数据仓-库项目规划，我想，除了技术方面的东西外，是不是还要有些关于后续运营和治理的规划？既然提到要重视业务部门，那么和业务的互动以及业务推动数据仓库的流程方面-就很重要了。只是一点建议啊。
>
库的具体问题，所谓不在其位不谋其职。
规划的中心思想是什么？中心思想就是确定架构扩展方向，数据扩展方向，模型改进方向，用已经规划过的，而且成功实施数年甚至10年以上的项目经验结合各
种技术和理论，规划面向未来发展的基础架构。如果没有那种成熟项目经验的规划，可能确实就是摸着石头过河，容易顾此失彼。
规划的最大好处是什么？目前接触到几家甲方的人员，他们的项目换过乙方，也换过方案，也重新梳理过模型，但是后来感觉项目投资和效果严重不成比例，项目
没连续性，重复投资大，移植成本过高，最终用户反应大。规划的最大好处就是项目延续性，整体性，用更合理的投资取得最大的成果。
规划在项目中的核心利益是什么？规划就是指名一个方向，从多个角度参考顶级成熟项目，指名项目发展方向。然后从现实角度出发，和各级领导一起讨论逐步推
进项目的详细计划，逐步完善数据仓库架构，如果没有规划，具体的一个个项目，就像无头的苍蝇，想到哪设计到哪，发现问题就去补一个问题，项目2年以后肯
定千种百孔，无法再延续下去，可能需要推翻再来。
如果说战略发展方向有关系的话，那么只有一点关系，就是企业高层想怎么去处理BI方面的事情，是上一个主题算一个主题，发现一个问题再补充一个问题，还
是从开始就制定出架构方向，然后一步步循序渐进地实施下去。
如果说像写书，我想未来写书也不是不可能，一直没时间写。不过既然在企业里做，规划仅仅是项目的前奏。在一个月内最终确定架构方向后，我已经把模型研
发、ETL优化纳入日程，为改善现有项目以及即将进行的新架构移植，并为下一个主题结合老主题做统一维度建模的第一个方案版本。一般理论书上不会说参考
模型和控制模型，但我会根据经验去研发适合公司的模型。因为这两种模型属于非业务主题模型，要高质量项目它们是必须的，如果要求不高，他们不是必须的，
或者没有成为体系，想到哪里设计那么一点点来补漏。
业务推动和数据仓库架构规划没有矛盾，数据仓库架构只是支撑整个系统的基础，业务变化和改进是另一个层面的事情。上面讲到的两个辅助模型，就是帮助处理
业务变化和改进的辅助体，这样主体模型才能更好地体现业务的变化甚至业务组织机构的变化和改进。
On 3月23日, 上午10时33分, huangkan <erichuangta...@gmail.com> wrote:
> "规划的事情很重要，持续的改进更重要"。数据仓库规划和企业战略发展方向规划还是有点关系的，比如，你的数据仓库建设的着手点可能不一样。另外，既然是数据仓-库项目规划，我想，除了技术方面的东西外，是不是还要有些关于后续运营和治理的规划？既然提到要重视业务部门，那么和业务的互动以及业务推动数据仓库的流程方面-就很重要了。只是一点建议啊。
>
Qing
Mar 23, 2008, 11:17:02 PM3/23/08
to tt...@googlegroups.com
咦，被点名了。
偶尔有一种感觉，觉得innovate跟interstage其实是一个人，自己在跟自己玩天使与恶魔的游戏，不知道从什么时候就耗上了，大家看看，名字都是以in开始，以e结束，难道是巧合么？
对于这种讨论我没什么好说的，挺有意思，只要讨论的各方不要太在意太生气，那样就亏待了自己。
有功夫我也参战。
Goldenfish3
Mar 23, 2008, 11:32:53 PM3/23/08
to tt...@googlegroups.com
论坛里确实得有正反双方，有争论才能有认证思考和深入探讨。
Mike Wen
Mar 24, 2008, 12:38:18 PM3/24/08
to tt...@googlegroups.com
呵呵... 感觉两人各站一边,一个偏业务,一个偏技术. 业务嘛, 在国内大部分涉及到信息化的都有点漂, 最后就成了所谓的"只要搞个方案上去,磨洋工的实施".技术,很多时候由于个人的从业经验限制所限,也不是很多人涉及到成熟模型的使用或者调整.最后也就成了"项目2年以后肯定千种百孔，无法再延续下去，可能需要推翻再来"~
我个人感觉项目本身就是并非说在项目做完后就大家都撒手的, 我个人了解, IBM在国内的制造业,从实施了SAP后就一直是自己的sap顾问TEAM在维护/更改. 期间提一个需求最低是十万美金(类似我们平时项目中一个小的改动),到现在为止他们(忘了这企业现在叫联想了)很多sap原有的模块都完全自己重新设计实现过了. 如果照我们定义项目本身这样说,岂非是SAP太烂,或者是说IBM的仁兄自己拐自己?
这我个人觉得是我们在做项目时必须面对的问题. 乙方说我做项目啥都能做, 甲方就说你结项时必须啥都能满足, 哎...谁又可以呢?
建议两位仁兄继续斗, 如果天天ttnn都有这样斗来斗去,相信我们观众都获益匪浅.
--
GuangZhou.China
我个人感觉项目本身就是并非说在项目做完后就大家都撒手的, 我个人了解, IBM在国内的制造业,从实施了SAP后就一直是自己的sap顾问TEAM在维护/更改. 期间提一个需求最低是十万美金(类似我们平时项目中一个小的改动),到现在为止他们(忘了这企业现在叫联想了)很多sap原有的模块都完全自己重新设计实现过了. 如果照我们定义项目本身这样说,岂非是SAP太烂,或者是说IBM的仁兄自己拐自己?
这我个人觉得是我们在做项目时必须面对的问题. 乙方说我做项目啥都能做, 甲方就说你结项时必须啥都能满足, 哎...谁又可以呢?
建议两位仁兄继续斗, 如果天天ttnn都有这样斗来斗去,相信我们观众都获益匪浅.
在08-3-24，Goldenfish3 <golde...@163.com> 写道：
论坛里确实得有正反双方，有争论才能有认证思考和深入探讨。
--
GuangZhou.China
innovate511
Mar 25, 2008, 8:21:53 AM3/25/08
to ttnn BI 观点
任何一个系统都需要维护和升级，我想问下，SAP模块重新设计，也属于产品2次开发吧，那是SAP系统的升级，还是架构推倒重来呢？数据仓库有个升级内
容就是数据集市重组，目的一样的，但这是可预见，易操作、相对低投资的升级内容，这和推倒重来有本质的区别。
良好的规划和没有良好规划的区别不在于后面是否有维护，而在于是否在后期项目中很多工作重复或者项目推倒重来。而规划就是站在一定的高度，架构总体和细
节上逻辑严密并有相当的扩展能力，不仅仅在数据量上，还体现在业务变化、商业模式变化和组织机构变化，以及BI更深层次的业务挖掘、更好要求的数据集
成、安全要求上。
如果乙方说啥都能做，0 bug，什么的，以及甲方说我的要求什么都要满足，那只能说明一方没经验，或者太吹，另一方对BI太无知，需要教育，做这种项
目，如果甲方死扛的话，乙方必亏，如果教育无效，大家还是闪人吧。
On 3月25日, 上午12时38分, "Mike Wen" <tya....@gmail.com> wrote:
> 呵呵... 感觉两人各站一边,一个偏业务,一个偏技术. 业务嘛, 在国内大部分涉及到信息化的都有点漂, 最后就成了所谓的"只要搞个方案上去,磨洋工的实施
> ".技术,很多时候由于个人的从业经验限制所限,也不是很多人涉及到成熟模型的使用或者调整.最后也就成了
> "项目2年以后肯定千种百孔，无法再延续下去，可能需要推翻再来"~
>
> 我个人感觉项目本身就是并非说在项目做完后就大家都撒手的, 我个人了解,
> IBM在国内的制造业,从实施了SAP后就一直是自己的sap顾问TEAM在维护/更改.
> 期间提一个需求最低是十万美金(类似我们平时项目中一个小的改动),到现在为止他们(忘了这企业现在叫联想了)很多sap原有的模块都完全自己重新设计实现过了-.
>
>
>
> > 论坛里确实得有正反双方，有争论才能有认证思考和深入探讨。
>
> --
> GuangZhou.China
容就是数据集市重组，目的一样的，但这是可预见，易操作、相对低投资的升级内容，这和推倒重来有本质的区别。
良好的规划和没有良好规划的区别不在于后面是否有维护，而在于是否在后期项目中很多工作重复或者项目推倒重来。而规划就是站在一定的高度，架构总体和细
节上逻辑严密并有相当的扩展能力，不仅仅在数据量上，还体现在业务变化、商业模式变化和组织机构变化，以及BI更深层次的业务挖掘、更好要求的数据集
成、安全要求上。
如果乙方说啥都能做，0 bug，什么的，以及甲方说我的要求什么都要满足，那只能说明一方没经验，或者太吹，另一方对BI太无知，需要教育，做这种项
目，如果甲方死扛的话，乙方必亏，如果教育无效，大家还是闪人吧。
On 3月25日, 上午12时38分, "Mike Wen" <tya....@gmail.com> wrote:
> 呵呵... 感觉两人各站一边,一个偏业务,一个偏技术. 业务嘛, 在国内大部分涉及到信息化的都有点漂, 最后就成了所谓的"只要搞个方案上去,磨洋工的实施
> ".技术,很多时候由于个人的从业经验限制所限,也不是很多人涉及到成熟模型的使用或者调整.最后也就成了
> "项目2年以后肯定千种百孔，无法再延续下去，可能需要推翻再来"~
>
> 我个人感觉项目本身就是并非说在项目做完后就大家都撒手的, 我个人了解,
> IBM在国内的制造业,从实施了SAP后就一直是自己的sap顾问TEAM在维护/更改.
> 如果照我们定义项目本身这样说,岂非是SAP太烂,或者是说IBM的仁兄自己拐自己?
> 这我个人觉得是我们在做项目时必须面对的问题. 乙方说我做项目啥都能做, 甲方就说你结项时必须啥都能满足, 哎...谁又可以呢?
>
> 建议两位仁兄继续斗, 如果天天ttnn都有这样斗来斗去,相信我们观众都获益匪浅.
>
> 在08-3-24，Goldenfish3 <goldenfi...@163.com> 写道：
> 这我个人觉得是我们在做项目时必须面对的问题. 乙方说我做项目啥都能做, 甲方就说你结项时必须啥都能满足, 哎...谁又可以呢?
>
> 建议两位仁兄继续斗, 如果天天ttnn都有这样斗来斗去,相信我们观众都获益匪浅.
>
>
>
>
> > 论坛里确实得有正反双方，有争论才能有认证思考和深入探讨。
>
> --
> GuangZhou.China
zpdxi...@gmail.com
Mar 25, 2008, 9:04:06 AM3/25/08
to tt...@googlegroups.com
思路不管怎么规划，项目不管怎么做，都要本着“以人为本”的原则，如果脱离了这个原则，就要有人不爽，有人不爽就要出事。
当然以人为本也要有所取舍的
2008-03-25
发件人： Mike Wen
发送时间： 2008-03-25 00:38:45
innovate511
Mar 26, 2008, 7:24:13 AM3/26/08
to ttnn BI 观点
BI是新的组，做好了各级领导都有好处，不存在谁不爽的问题。可能有部分朋友误以为我的规划要抢部分人的饭碗，或者夺取人家的工作职责吧。
远期规划只是个嚼头，要描述清楚，那不得写一本书出来了，只能粗略勾画出来。要搞出能看得见的东西，还得重点在数据架构上，无论是远期，还是近期，都是
架构中心部分，一边由物理架构和ETL架构支持，一边由前端架构实现BI。
On 3月25日, 下午9时04分, "zpdxiogx...@gmail.com" <zpdxiogx...@gmail.com>
wrote:
远期规划只是个嚼头，要描述清楚，那不得写一本书出来了，只能粗略勾画出来。要搞出能看得见的东西，还得重点在数据架构上，无论是远期，还是近期，都是
架构中心部分，一边由物理架构和ETL架构支持，一边由前端架构实现BI。
On 3月25日, 下午9时04分, "zpdxiogx...@gmail.com" <zpdxiogx...@gmail.com>
wrote:
> 思路不管怎么规划，项目不管怎么做，都要本着“以人为本”的原则，如果脱离了这个原则，就要有人不爽，有人不爽就要出事。
> 当然以人为本也要有所取舍的
>
> 2008-03-25
>
> zpdxiogx...@gmail.com
> 当然以人为本也要有所取舍的
>
> 2008-03-25
>
interstage
Mar 27, 2008, 1:20:14 AM3/27/08
to ttnn BI 观点
对你DW的逻辑架构规划无疑义(ODS-EDW-CDW-BI展现),其实我也是向我的客户在描述技术层面上这样提的,但在中国整个环境都充满着浮躁的
时代,你越这样提,越被民企老板以投资回报率(ROI)来询问,你知道的,技术人员很难搞清楚ROI,所以,基本上很难说服老板,除非这个民企的CIO
在公司很又强势,如果你所在的企业是国企,老板一般不会问你ROI,只关心花钱多不多,越多越好,因为他能拿钱,这就是中国DWBI的现状.
所以,你这个DW的逻辑架构规划对于中国企业的现状来讲,特别是民企,是没意义的.有句话说的好,领先一步是先行者,领先3步是先烈.
以上说法是基于你是真心想做架构规划的建议,除非你另有自己的想法.业务和数据永远是说不清的,但业务永远是驱动数据,当然数据也可以反过来影响业
务.我一直在说的,数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的
唯一条件,目前的BIERS以为自己的DWBI系统能解决企业战略管理的问题,这才是可悲的.
时代,你越这样提,越被民企老板以投资回报率(ROI)来询问,你知道的,技术人员很难搞清楚ROI,所以,基本上很难说服老板,除非这个民企的CIO
在公司很又强势,如果你所在的企业是国企,老板一般不会问你ROI,只关心花钱多不多,越多越好,因为他能拿钱,这就是中国DWBI的现状.
所以,你这个DW的逻辑架构规划对于中国企业的现状来讲,特别是民企,是没意义的.有句话说的好,领先一步是先行者,领先3步是先烈.
以上说法是基于你是真心想做架构规划的建议,除非你另有自己的想法.业务和数据永远是说不清的,但业务永远是驱动数据,当然数据也可以反过来影响业
务.我一直在说的,数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的
唯一条件,目前的BIERS以为自己的DWBI系统能解决企业战略管理的问题,这才是可悲的.
Qing
Mar 27, 2008, 1:57:19 AM3/27/08
to tt...@googlegroups.com
咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
看来，还是那个标题惹得祸。
2008/3/27 interstage <buer...@gmail.com>:
...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。
innovate511
Mar 27, 2008, 8:39:43 AM3/27/08
to ttnn BI 观点
这个命名不是我说的，而是公司高层说的。
而且确实也是规划，从目前现状来看，公司要求ROI是100%的，今年会上两个项目，一个是数据仓库相关的业务项目（数据仓库提供数据，但非BI），一
个是新的大主题。
从现实出发，我是把以前3个500强企业项目经验中架构结合来用，架构十分庞大和复杂，要说1年内马上建起来，可能么？不可能！而且目前公司规模和现实
BI以及其他数据需求远没500强企业那么大，也没必要搞那么大的架构，我当初和公司高层谈的时候，就提到，架构规划是把我的经验拿出来，人家500强
企业大概架构是什么样子，但是实际操作，只能再从当前的条件、当前需求从小架构做起，然后朝着方向，一步一步
> 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可-我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
>
>
>
> > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
而且确实也是规划，从目前现状来看，公司要求ROI是100%的，今年会上两个项目，一个是数据仓库相关的业务项目（数据仓库提供数据，但非BI），一
个是新的大主题。
从现实出发，我是把以前3个500强企业项目经验中架构结合来用，架构十分庞大和复杂，要说1年内马上建起来，可能么？不可能！而且目前公司规模和现实
BI以及其他数据需求远没500强企业那么大，也没必要搞那么大的架构，我当初和公司高层谈的时候，就提到，架构规划是把我的经验拿出来，人家500强
企业大概架构是什么样子，但是实际操作，只能再从当前的条件、当前需求从小架构做起，然后朝着方向，一步一步
> 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可-我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
>
> 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> 看来，还是那个标题惹得祸。
>
> 2008/3/27 interstage <buer0...@gmail.com>:
> 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> 看来，还是那个标题惹得祸。
>
>
>
>
> > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
innovate511
Mar 27, 2008, 8:57:17 AM3/27/08
to ttnn BI 观点
晕了，group还是没论坛方便，不能编辑。刚才打字不知道按到什么键了，还没写完就发送了......。
刚才说到规划其实就是一个面向500强级需求的数据仓库架构，而现状还远没这需求，而技术是为需求服务，所以无论从ROI角度考虑，还是从必要性考虑，
都没必要真正去设计这么个架构马上用起来。说白了，就是拿一个技术方向的架构，让老板看看，未来我们的架构可以是什么样的，我们的BI团队未来可以只考
虑业务、业务结合技术，而不用考虑架构难题，同时也满足老板的一定的虚荣心。
那么要在最近1、2年即将上的项目中，如何朝规划中的方向前进呢？于是我把核心放到数据架构上来，数据架构从远期来看虽然更复杂，但毕竟是最直观的架构
技术，近期也可以做很多事情，只是远没有规划中那么完美，也没那么多精力和人力去一年内完成，但我心理清楚可以朝哪些方面扩展设计。
至于这里XD们为啥那么反感规划，实在没想明白，其实也就是拿做奔驰宝马的经验设计QQ而已，并给老板看看，未来的架构能达到如何如何，不过分吧？
> 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
> 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可-我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
刚才说到规划其实就是一个面向500强级需求的数据仓库架构，而现状还远没这需求，而技术是为需求服务，所以无论从ROI角度考虑，还是从必要性考虑，
都没必要真正去设计这么个架构马上用起来。说白了，就是拿一个技术方向的架构，让老板看看，未来我们的架构可以是什么样的，我们的BI团队未来可以只考
虑业务、业务结合技术，而不用考虑架构难题，同时也满足老板的一定的虚荣心。
那么要在最近1、2年即将上的项目中，如何朝规划中的方向前进呢？于是我把核心放到数据架构上来，数据架构从远期来看虽然更复杂，但毕竟是最直观的架构
技术，近期也可以做很多事情，只是远没有规划中那么完美，也没那么多精力和人力去一年内完成，但我心理清楚可以朝哪些方面扩展设计。
至于这里XD们为啥那么反感规划，实在没想明白，其实也就是拿做奔驰宝马的经验设计QQ而已，并给老板看看，未来的架构能达到如何如何，不过分吧？
> 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
> 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可-我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
>
> 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> 看来，还是那个标题惹得祸。
>
> 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> 看来，还是那个标题惹得祸。
>
raullew
Mar 27, 2008, 11:31:27 AM3/27/08
to ttnn BI 观点
谈架构就像放映ppt，是很虚的东西，规划还是在公司内部讨论的最清楚
技术上，我是支持你的四层建模方法的，也成功实践过，不过那是因为有一个用了4年的老系统要被替换，踩着前人的尸体总结出来的，所以目前对新公司的DW
还没啥想法，可能以后也不会有。。。
On Mar 27, 8:57 pm, innovate511 <innovate...@gmail.com> wrote:
> 晕了，group还是没论坛方便，不能编辑。刚才打字不知道按到什么键了，还没写完就发送了......。
>
> 刚才说到规划其实就是一个面向500强级需求的数据仓库架构，而现状还远没这需求，而技术是为需求服务，所以无论从ROI角度考虑，还是从必要性考虑，
> 都没必要真正去设计这么个架构马上用起来。说白了，就是拿一个技术方向的架构，让老板看看，未来我们的架构可以是什么样的，我们的BI团队未来可以只考
> 虑业务、业务结合技术，而不用考虑架构难题，同时也满足老板的一定的虚荣心。
>
> 那么要在最近1、2年即将上的项目中，如何朝规划中的方向前进呢？于是我把核心放到数据架构上来，数据架构从远期来看虽然更复杂，但毕竟是最直观的架构
> 技术，近期也可以做很多事情，只是远没有规划中那么完美，也没那么多精力和人力去一年内完成，但我心理清楚可以朝哪些方面扩展设计。
>
> 至于这里XD们为啥那么反感规划，实在没想明白，其实也就是拿做奔驰宝马的经验设计QQ而已，并给老板看看，未来的架构能达到如何如何，不过分吧？
>
> On 3月27日, 下午1时57分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
> > 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可--我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
技术上，我是支持你的四层建模方法的，也成功实践过，不过那是因为有一个用了4年的老系统要被替换，踩着前人的尸体总结出来的，所以目前对新公司的DW
还没啥想法，可能以后也不会有。。。
On Mar 27, 8:57 pm, innovate511 <innovate...@gmail.com> wrote:
> 晕了，group还是没论坛方便，不能编辑。刚才打字不知道按到什么键了，还没写完就发送了......。
>
> 刚才说到规划其实就是一个面向500强级需求的数据仓库架构，而现状还远没这需求，而技术是为需求服务，所以无论从ROI角度考虑，还是从必要性考虑，
> 都没必要真正去设计这么个架构马上用起来。说白了，就是拿一个技术方向的架构，让老板看看，未来我们的架构可以是什么样的，我们的BI团队未来可以只考
> 虑业务、业务结合技术，而不用考虑架构难题，同时也满足老板的一定的虚荣心。
>
> 那么要在最近1、2年即将上的项目中，如何朝规划中的方向前进呢？于是我把核心放到数据架构上来，数据架构从远期来看虽然更复杂，但毕竟是最直观的架构
> 技术，近期也可以做很多事情，只是远没有规划中那么完美，也没那么多精力和人力去一年内完成，但我心理清楚可以朝哪些方面扩展设计。
>
> 至于这里XD们为啥那么反感规划，实在没想明白，其实也就是拿做奔驰宝马的经验设计QQ而已，并给老板看看，未来的架构能达到如何如何，不过分吧？
>
> On 3月27日, 下午1时57分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
>
> > 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> > 看来，还是那个标题惹得祸。
>
> > 2008/3/27 interstage <buer0...@gmail.com>:
>
> > > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
> > - 显示引用的文字 -- Hide quoted text -
> > 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> > 看来，还是那个标题惹得祸。
>
> > 2008/3/27 interstage <buer0...@gmail.com>:
>
> > > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
interstage
Mar 27, 2008, 12:18:28 PM3/27/08
to ttnn BI 观点
呵呵,既然称为规划的东西,至少是一个战略层面的东西,很少在战术上谈"规划"两字,在战术上只谈"规范"2字,而任何提升为战略层面的东西,一定是为
了企业战略管理的一部分. 这就是你我的差异.你动不动把标题写成"数据仓库项目中远期规划",这个东西在我眼里不是你能干成的.如果你写成"数据仓库
项目规范",我就不会说你在整这个没用的东西了.
了企业战略管理的一部分. 这就是你我的差异.你动不动把标题写成"数据仓库项目中远期规划",这个东西在我眼里不是你能干成的.如果你写成"数据仓库
项目规范",我就不会说你在整这个没用的东西了.
interstage
Mar 27, 2008, 12:33:58 PM3/27/08
to ttnn BI 观点
"这个命名不是我说的，而是公司高层说的" 那要么说明你提交的这种"规范性"的描述去套"规划性"的东西跑题目了,要么领导就是想让你成长起来,
从"规划"的角度看问题,我还是在你的"甲方工作几点"提出的那句话,其实你去甲方,更重要的是学习和总结出与你原来存在DW经验不一样的角度和思考方
式,这才是你最有价值的东西.而你的"甲方工作几点"在我眼里根本不是你具体的工作方法,只是你平时DW经验的自己表达方式,放在任何一个甲方都一样,
和你实际这个甲方的工作岗位没有任何关系.
On 3月27日, 下午8时39分, innovate511 <innovate...@gmail.com> wrote:
> 这个命名不是我说的，而是公司高层说的。
>
> 而且确实也是规划，从目前现状来看，公司要求ROI是100%的，今年会上两个项目，一个是数据仓库相关的业务项目（数据仓库提供数据，但非BI），一
> 个是新的大主题。
>
> 从现实出发，我是把以前3个500强企业项目经验中架构结合来用，架构十分庞大和复杂，要说1年内马上建起来，可能么？不可能！而且目前公司规模和现实
> BI以及其他数据需求远没500强企业那么大，也没必要搞那么大的架构，我当初和公司高层谈的时候，就提到，架构规划是把我的经验拿出来，人家500强
> 企业大概架构是什么样子，但是实际操作，只能再从当前的条件、当前需求从小架构做起，然后朝着方向，一步一步
>
> On 3月27日, 下午1时57分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
> > 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可--我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
>
> - 显示引用的文字 -
从"规划"的角度看问题,我还是在你的"甲方工作几点"提出的那句话,其实你去甲方,更重要的是学习和总结出与你原来存在DW经验不一样的角度和思考方
式,这才是你最有价值的东西.而你的"甲方工作几点"在我眼里根本不是你具体的工作方法,只是你平时DW经验的自己表达方式,放在任何一个甲方都一样,
和你实际这个甲方的工作岗位没有任何关系.
On 3月27日, 下午8时39分, innovate511 <innovate...@gmail.com> wrote:
> 这个命名不是我说的，而是公司高层说的。
>
> 而且确实也是规划，从目前现状来看，公司要求ROI是100%的，今年会上两个项目，一个是数据仓库相关的业务项目（数据仓库提供数据，但非BI），一
> 个是新的大主题。
>
> 从现实出发，我是把以前3个500强企业项目经验中架构结合来用，架构十分庞大和复杂，要说1年内马上建起来，可能么？不可能！而且目前公司规模和现实
> BI以及其他数据需求远没500强企业那么大，也没必要搞那么大的架构，我当初和公司高层谈的时候，就提到，架构规划是把我的经验拿出来，人家500强
> 企业大概架构是什么样子，但是实际操作，只能再从当前的条件、当前需求从小架构做起，然后朝着方向，一步一步
>
> On 3月27日, 下午1时57分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
>
> > 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> > 看来，还是那个标题惹得祸。
>
> > 2008/3/27 interstage <buer0...@gmail.com>:
>
> > > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
> > - 显示引用的文字 -- 隐藏被引用文字 -
> > 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> > 看来，还是那个标题惹得祸。
>
> > 2008/3/27 interstage <buer0...@gmail.com>:
>
> > > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
>
> - 显示引用的文字 -
interstage
Mar 27, 2008, 12:59:57 PM3/27/08
to ttnn BI 观点
呵呵,你认为实施10年的大型DW"10多TB，数万最终用户，99年开始规划建设"是非常成功的吗?OK,就算是成功的,10年后DW是不是真的是
10前规划者原来设计的想法吗,不一定,连Bill Inmon在提出DW的时候,也是在争论中发展成DW2.0.而且现在10T的数据并不算大,现在
配磁盘阵列的时候,肯定都在50T以上,而且数据仓库有数据膨胀的问题,1T的数据库在数据膨胀后一般变成3T,很快10T就解决了.记得我在9年前的
一个晚上为一个数据库升级,那个数据量当时就有500G,搞的当时很紧张.9年后的现在,我听到这个DW数据量为"10T",真的不觉的很牛比.
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
10前规划者原来设计的想法吗,不一定,连Bill Inmon在提出DW的时候,也是在争论中发展成DW2.0.而且现在10T的数据并不算大,现在
配磁盘阵列的时候,肯定都在50T以上,而且数据仓库有数据膨胀的问题,1T的数据库在数据膨胀后一般变成3T,很快10T就解决了.记得我在9年前的
一个晚上为一个数据库升级,那个数据量当时就有500G,搞的当时很紧张.9年后的现在,我听到这个DW数据量为"10T",真的不觉的很牛比.
>
> - 显示引用的文字 -
innovate511
Mar 28, 2008, 11:18:29 AM3/28/08
to ttnn BI 观点
其实看你从什么角度去看架构，对于老板来说，只要让他知道，这个架构在将来能实现哪些BI和数据集成功能，这样的架构，各个结构部分有什么优势，有什么
必要性。对于公司的变化，架构是否能在技术上做支持。另一方面来说，项目流程和管理上，也是能沿着规划的道路走的必要条件，比如项目设计规范、开发规
范、测试规范、命名规范，然后是项目管理流程。如果这些没有管理，技术架构就是空设。看看现在的项目，有多少是按照规范走的？
从技术的角度，首先要判断公司下答的任务，是否能在现有人力、财力下做好每一个技术架构，如果做不到，那么只能做退让。而看现在厂商能卖的方案，无非是
产品解决方案，包括数据库、ETL、BI前端产品等，然后就是行业模型解决方案。他们都是架构中的一部分，那么还缺什么？那就是对数据层次的细分、模型
层次细分。
因为我们的产品只是平面的，数据库就是存储工具，ETL就是处理数据并管理技术元数据，BI工具可展现，可管理业务元数据，行业模型再稍微扩展下就解决
了初步的BI业务数据的问题。于是从简单架构来看，从单一角度考虑技术和业务问题，这些已经足够了。不过要吸取前人的经验，那就只有看看项目实施之后，
会遇到什么问题，这样我在帖子之处就提出我们的架构需要支撑这些。
从技术角度来看，处理效率问题，在我提到的几个方面已经有对应的解决方案了，对于公司业务变化、结构性变化，那么从本质来看就是跟踪其变化，于是单纯的
管理是解决不了这个问题的，于是我在业务数据管理的方案中提出，用辅助模型跟踪其业务元数据变化，并和主体模型的相应维表关联，其本质和变化维一样，只
是变化维只是维的数据在变，而我们为了防止模型架构的大改动，使用了类似办法，跟踪维自身的变化。
然而从各位多年项目经验不难看出，除了我们在不断追求更好的技术和架构的同时，还存在很多不稳定因素，那就是流程不规范，流程不规范，项目一大，10多
人甚至几十人如何在一个大项目中做到围绕项目规范去做，就显得非常重要了。
但我们不能在一个帖子里把问题扯太大了，这里主要从技术角度考虑。
On 3月27日, 下午11时31分, raullew <raul...@hotmail.com> wrote:
> 谈架构就像放映ppt，是很虚的东西，规划还是在公司内部讨论的最清楚
> 技术上，我是支持你的四层建模方法的，也成功实践过，不过那是因为有一个用了4年的老系统要被替换，踩着前人的尸体总结出来的，所以目前对新公司的DW
> 还没啥想法，可能以后也不会有。。。
>
> On Mar 27, 8:57 pm, innovate511 <innovate...@gmail.com> wrote:
>
>
>
> > 晕了，group还是没论坛方便，不能编辑。刚才打字不知道按到什么键了，还没写完就发送了......。
>
> > 刚才说到规划其实就是一个面向500强级需求的数据仓库架构，而现状还远没这需求，而技术是为需求服务，所以无论从ROI角度考虑，还是从必要性考虑，
> > 都没必要真正去设计这么个架构马上用起来。说白了，就是拿一个技术方向的架构，让老板看看，未来我们的架构可以是什么样的，我们的BI团队未来可以只考
> > 虑业务、业务结合技术，而不用考虑架构难题，同时也满足老板的一定的虚荣心。
>
> > 那么要在最近1、2年即将上的项目中，如何朝规划中的方向前进呢？于是我把核心放到数据架构上来，数据架构从远期来看虽然更复杂，但毕竟是最直观的架构
> > 技术，近期也可以做很多事情，只是远没有规划中那么完美，也没那么多精力和人力去一年内完成，但我心理清楚可以朝哪些方面扩展设计。
>
> > 至于这里XD们为啥那么反感规划，实在没想明白，其实也就是拿做奔驰宝马的经验设计QQ而已，并给老板看看，未来的架构能达到如何如何，不过分吧？
>
> > On 3月27日, 下午1时57分, Qing <happys...@gmail.com> wrote:
>
> > > 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
> > > 搞架构，听起来是个技术活，搞规划，听起来就是个忽悠活。这里面不知道有多少利益在里面。所以说不要innovate说不要担心抢了谁的饭碗，当然你不担心，可---我相信肯定是有人担心的。你要搞规划干脆就轰轰烈烈来一场，但看起来你考虑的事情并非是规划，是架构。
>
> - 显示引用的文字 -
必要性。对于公司的变化，架构是否能在技术上做支持。另一方面来说，项目流程和管理上，也是能沿着规划的道路走的必要条件，比如项目设计规范、开发规
范、测试规范、命名规范，然后是项目管理流程。如果这些没有管理，技术架构就是空设。看看现在的项目，有多少是按照规范走的？
从技术的角度，首先要判断公司下答的任务，是否能在现有人力、财力下做好每一个技术架构，如果做不到，那么只能做退让。而看现在厂商能卖的方案，无非是
产品解决方案，包括数据库、ETL、BI前端产品等，然后就是行业模型解决方案。他们都是架构中的一部分，那么还缺什么？那就是对数据层次的细分、模型
层次细分。
因为我们的产品只是平面的，数据库就是存储工具，ETL就是处理数据并管理技术元数据，BI工具可展现，可管理业务元数据，行业模型再稍微扩展下就解决
了初步的BI业务数据的问题。于是从简单架构来看，从单一角度考虑技术和业务问题，这些已经足够了。不过要吸取前人的经验，那就只有看看项目实施之后，
会遇到什么问题，这样我在帖子之处就提出我们的架构需要支撑这些。
从技术角度来看，处理效率问题，在我提到的几个方面已经有对应的解决方案了，对于公司业务变化、结构性变化，那么从本质来看就是跟踪其变化，于是单纯的
管理是解决不了这个问题的，于是我在业务数据管理的方案中提出，用辅助模型跟踪其业务元数据变化，并和主体模型的相应维表关联，其本质和变化维一样，只
是变化维只是维的数据在变，而我们为了防止模型架构的大改动，使用了类似办法，跟踪维自身的变化。
然而从各位多年项目经验不难看出，除了我们在不断追求更好的技术和架构的同时，还存在很多不稳定因素，那就是流程不规范，流程不规范，项目一大，10多
人甚至几十人如何在一个大项目中做到围绕项目规范去做，就显得非常重要了。
但我们不能在一个帖子里把问题扯太大了，这里主要从技术角度考虑。
On 3月27日, 下午11时31分, raullew <raul...@hotmail.com> wrote:
> 谈架构就像放映ppt，是很虚的东西，规划还是在公司内部讨论的最清楚
> 技术上，我是支持你的四层建模方法的，也成功实践过，不过那是因为有一个用了4年的老系统要被替换，踩着前人的尸体总结出来的，所以目前对新公司的DW
> 还没啥想法，可能以后也不会有。。。
>
> On Mar 27, 8:57 pm, innovate511 <innovate...@gmail.com> wrote:
>
>
>
> > 晕了，group还是没论坛方便，不能编辑。刚才打字不知道按到什么键了，还没写完就发送了......。
>
> > 刚才说到规划其实就是一个面向500强级需求的数据仓库架构，而现状还远没这需求，而技术是为需求服务，所以无论从ROI角度考虑，还是从必要性考虑，
> > 都没必要真正去设计这么个架构马上用起来。说白了，就是拿一个技术方向的架构，让老板看看，未来我们的架构可以是什么样的，我们的BI团队未来可以只考
> > 虑业务、业务结合技术，而不用考虑架构难题，同时也满足老板的一定的虚荣心。
>
> > 那么要在最近1、2年即将上的项目中，如何朝规划中的方向前进呢？于是我把核心放到数据架构上来，数据架构从远期来看虽然更复杂，但毕竟是最直观的架构
> > 技术，近期也可以做很多事情，只是远没有规划中那么完美，也没那么多精力和人力去一年内完成，但我心理清楚可以朝哪些方面扩展设计。
>
> > 至于这里XD们为啥那么反感规划，实在没想明白，其实也就是拿做奔驰宝马的经验设计QQ而已，并给老板看看，未来的架构能达到如何如何，不过分吧？
>
> > On 3月27日, 下午1时57分, Qing <happys...@gmail.com> wrote:
>
> > > 咦，刚写了一篇从知识到智慧，看到你这一说，心有灵犀？
>
>
> > > 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> > > 看来，还是那个标题惹得祸。
>
> > > 2008/3/27 interstage <buer0...@gmail.com>:
>
> > > > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
> > > - 显示引用的文字 -- Hide quoted text -
>
> > - Show quoted text -- 隐藏被引用文字 -
> > > 所以，我估计这就是interstage为什么总是拿这说事的缘故。甚至在一开始并不反对架构本身，但因为你因规划之名的架构，反对了。
>
> > > 看来，还是那个标题惹得祸。
>
> > > 2008/3/27 interstage <buer0...@gmail.com>:
>
> > > > ...数据转化为知识,这是IT人员干的活,知识转化为智慧(战略管理),是管理者干的活,而很多情况下,知识不是得到智慧(战略管理)的唯一条件,。。。- 隐藏被引用文字 -
>
> > > - 显示引用的文字 -- Hide quoted text -
>
>
> - 显示引用的文字 -
innovate511
Mar 28, 2008, 11:25:25 AM3/28/08
to ttnn BI 观点
项目规范？太偏题了吧？规范只是从项目管理的角度。而从技术方面的角度看，举个简单的例子，目前我还没听说过国内哪个项目有人专门设计辅助模型跟踪业务
元数据的，不相信国内快速成长的企业，业务自身的定义和层次结构不经常变化？那么只是单纯从一个技术角度去设计，也难怪模型会经常有大的改动，而临时存
储层也在不断改动，因为漫无目的，临时区无结构可言，于是也无人去管理。
> > 呢？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
元数据的，不相信国内快速成长的企业，业务自身的定义和层次结构不经常变化？那么只是单纯从一个技术角度去设计，也难怪模型会经常有大的改动，而临时存
储层也在不断改动，因为漫无目的，临时区无结构可言，于是也无人去管理。
>
> - 显示引用的文字 -
innovate511
Mar 29, 2008, 6:48:54 AM3/29/08
to ttnn BI 观点
随着企业信息化的发展，未来除了BI分析报表、固定报表外，还需要考虑各个系统的接口，比如企业计划系统、数据挖掘系统、即时BI，业务系统统计度量集
成接口等等。如果没有一定的系统方面的规划，如何设计接口，如何和现有系统整合，不可能到时再摸着石头过河吧？
在老板看来，投资一个系统，不能只看眼前的小部分，还得看这个系统以后到底能做到什么地步，能起到多大作用，业界有哪些成功案例是这样一个数据大集成
的。
成接口等等。如果没有一定的系统方面的规划，如何设计接口，如何和现有系统整合，不可能到时再摸着石头过河吧？
在老板看来，投资一个系统，不能只看眼前的小部分，还得看这个系统以后到底能做到什么地步，能起到多大作用，业界有哪些成功案例是这样一个数据大集成
的。
innovate511
Apr 1, 2008, 10:16:23 AM4/1/08
to ttnn BI 观点
其实这就是一套最实际的持续改善、归纳和总结的过程。企业有两到三种不同的度量值，真是值、计划值甚至可能有预测值。那么没过一个周期，用户可以根据自
己的职责，把计划和真实值进行多维分析，及时发现问题，发现公司策略和现实的差距，发现差距的原因，然后再调整策略，调整计划，进行下一个循环。
越是快速变化的企业，周期越短，一般高科技、零售公司的最小计划和战略周期都是周，以便企业进行快速反应快速调整，不过我们国家目前还是以月为单位比较
多，需要一个适应过程。
己的职责，把计划和真实值进行多维分析，及时发现问题，发现公司策略和现实的差距，发现差距的原因，然后再调整策略，调整计划，进行下一个循环。
越是快速变化的企业，周期越短，一般高科技、零售公司的最小计划和战略周期都是周，以便企业进行快速反应快速调整，不过我们国家目前还是以月为单位比较
多，需要一个适应过程。
Reply all
Reply to author
Forward
0 new messages