BIDW项目容易忽略的几个重要细节总结

innovate511

不知道你说的“反馈效果不明显”是指具体哪些东西，原因是什么。

不过乙方有个很大的风险是，在项目调研前往往就被要求制定整个项目的计划时间表，而往往项目调研阶段是最容易多花时间的地方，造成后面要么加班都做不完，要么大家省掉原先计划好的流程，直接为报表准备数据，然后直接开发报表，根本谈不上架构和多好的项目质量。而这受伤的不仅仅是乙方，还有甲方，他们可能会重新考虑建设项目，也可能考虑多花人力和财力去维护。

所以调研阶段最好多预留些时间和商量空间，以免拔苗助长，也免得后来需求变化不断。

innovate511

现在先简单介绍下设计阶段。这个阶段也是我们容易忽略的地方，因为以往项目都是从ODS-DW-DM-CUBE/REPORT，只是根据情况，再在遇到具体困难后，再做些具体的设计调整，有时甚至开发过程中再做些设计调整。

我在另外一个帖子中写到过规划，有人说很理论化，其实不是，理论书上有从这些角度去看数据仓库的么？在设计中，不要说中长期规划的远见，至少得有一个项目范围内的预见吧？所以我一直不鼓励刚毕业的或者经验少的去直接设计商业项目，那样不但设计不出合理的项目，反而让他们的经验引向不合理的方向。

设计方面，前端BI主要看客户的需求，因为客户直接使用前端来实现BI。那么这里主要说数据仓库，没最终用户关心你后台架构怎么设计，只关心你怎么把BI做得更好用，更可靠。如果说客户更需要你帮他们用BI实现更多价值，那你说的应该是已经有成熟数据仓库架构的成熟项目，不在本主题讨论范围，如果客户连你的BI都不够信任，觉得不好使，后期的BI思想再好，又有什么用呢？

目前多数商业项目是从BI主题（也就是业务主导）引导数据仓库建设，技术主导的项目属于少数。这里以业务主导为例。业务主导的主要特点是需要较快见效，最终用户为主导方向，也是甲方考核方向。所以需要以合理的时间和投入去建设BI以及数据仓库，同时也考虑多个主题的统一性，以及使用效率问题，对于高价值数据，还需要自定义行级别的数据安全管理。当然理性的客户，最终还是会接受，在未来的规划中，范式建模的数据仓库的重要性。但他们的特点是想先产出效果，老板才能拍板再继续不断投资建设，于是你就不能强制推行Inmon先生主导的EDW，否则完成不了项目，自己就兜着吧。

那么这个时候主要几个要点，一是是否有统一维度建模（如果是某部门独立建的集市项目，那就不必了），是否模型中不但支持业务变化，还支持业务组织结构变化（如原来销售区域分3层，现在分4层，有结构交叉了）。在ETL方面是否有合理的增量抽取方案，每个包是否都有统一的检查流程，每个ETL过程是否有数据验证功能。模型设计中，PK，FK是否都设计合理。是否预测到数据量会带来架构瓶颈。而对于客户的合理的需求变更，数据集市是否有足够的变化空间，不要只有聚合汇总数据吧。

经常会碰到的项目开发中修改设计架构，往往就是对困难的估计不足，架构灵活空间太小，所以开头说的，如果设计偏差太大，后果不堪设想，会导致开发改变，重新测试，难免会顾此失彼，而且时间被严重浪费。后台设计空间要足够大，数据集市主要考虑功能，效率不是最大的问题，正常运行好几年的项目，一般数据集市都重组过2、3次了，效率问题每次重组后就不是问题了，如果说是空间换效率，那么数据集市相比数据仓库的数据量，应该不是大的问题。

gushangzao007

“反馈效果不明”是指我下发的调研表格（指标、统计报表清单反馈表）的反馈效果不明显。在例会中甲方也提出，需求调研期间可能会有所加长，让我做好心里准备，我的意见是，能不能先理出一些关键的、优先级高的、有数据来源的指标先做着。做出来看看，觉得好我们再继续往前进。

gushangzao007

楼主说的对于BI项目非常有指导意义，往楼主多多发帖哦！呵呵！

dahaizhixin2004

就是，楼主出书吧，我一定买。写出来会比那些大学“教授”强很多。

cityman_2008

国内做项目沟通是非常必要的，BI不同于其他的软件项目，其他软件开发项目一般是需求部门提出需求，建设部门负责建设，等建设完毕后，有需求部门使用。BI项目一开始需求并不是很明确，是在不断开发过程中，不断产生的，因此需要需求部门全程参与建设。对于乙方来讲，不但是集成商，还要是实施，在后期还需要是咨询方。因此，需要跟甲方沟通确定，最终验收的标准是什么，因为最后验收的时候，往往和当时的需求已经差很多了。

[ 本帖最后由 cityman_2008 于 2008-10-30 09:35 编辑 ]

pathwide

????????????????????//

Intelligencer

期待～！

yafeng

原帖由 cityman_2008 于 2008-10-30 09:33 发表
国内做项目沟通是非常必要的，BI不同于其他的软件项目，其他软件开发项目一般是需求部门提出需求，建设部门负责建设，等建设完毕后，有需求部门使用。BI项目一开始需求并不是很明确，是在不断开发过程中，不断产生的，因此需要需求部门全程参与建设。对于乙方来讲，不但是集成商，还要是实施，在后期还需要是咨询方。因此，需要跟甲方沟通确定，最终验收的标准是什么，因为最后验收的时候，往往和当时的需求已经差很多了。

很对

所以说按传统的软件工程方法实施BI项目是比较困难的。我倾向于使用敏捷开发。大家可以了解一下Scrum的开发模式。我个人感觉在项目中使用很好。

不过使用Scrum的最大威胁在于如果是FP (Fixed Price)的合同，则乙方的超支风险很大。所以使用敏捷开发的话，合同条款上一定要注意。

Garfield_Hu

在中国，不同的客户应该使用不同的策略，如果按照某个固定的格式与客户打交道，你会死得很惨。

有些客户。IT很强势，可以通过IT督促业务用户抓紧完成需求调研。

有些客户，业务很强势，可以通过比较高层的领导督促业务用户抓紧完成需求调研。

做项目，要厚脸皮，天天缠着他们，否则何年才能完成调研啊！