BIDW项目容易忽略的几个重要细节总结
7 views
Skip to first unread message
innovate511
Mar 19, 2008, 9:25:01 AM3/19/08
to ttnn BI 观点
BIDW项目容易忽略的几个重要细节总结
随着BIDW的发展，越来越多项目在各个行业的龙头企业和单位中展开。不过多数项目都存在着严重的加班和返工现象，透过这个表面，不难发现其中容易忽略
的因素。
1. 调研阶段漫无目的。调研阶段主要任务是通过项目范围，进行有效的业务需求调研，确定业务细节规则。特别是多家单位合作做项目，还可能出现互相推委
的情况。解决办法就是确定项目范围后，找到对应的业务人员，确定原始需求文档中不确定的业务规则，并和最终用户解释项目范围，不是每个需求都能随时变
更。最后是完善调研文档，由项目负责方确认。
2。设计阶段。设计阶段容易忽略项目要求和实际设计技术是否完全吻合。如果这个有所忽略，会造成比较严重的技术性后果。
3。开发阶段，这个阶段容易忽略分工和责任以及版本管理。如果是TL去负责相关文档，那么要使具体开发人员的相关信息和TL一致，开发人员需要参与开发
文档的一部分，需求变更时，开发人员必须要得到有效的通知。
4。测试阶段，这个阶段容易忽略测试细节，漏掉测试内容。这个阶段需要业务和相关数据模型熟悉的人参与，并审核测试结果。
5。实施阶段，这个阶段容易忽略实施细节文档，在实施上线的时候，由于是环境的迁移，细节决定一切。同时需要注意客户使用跟踪，因为正式环境也许有测试
环境没有的陷阱。
6。维护阶段，这个阶段容易忽略需求变更和增加后必要的测试环节，需要进行一定的回归测试，以确保整体项目质量。
最后是甲方需要审核项目各阶段需要提交的内容，不然在实施阶段补充，已经来不及了。
随着BIDW的发展，越来越多项目在各个行业的龙头企业和单位中展开。不过多数项目都存在着严重的加班和返工现象，透过这个表面，不难发现其中容易忽略
的因素。
1. 调研阶段漫无目的。调研阶段主要任务是通过项目范围，进行有效的业务需求调研，确定业务细节规则。特别是多家单位合作做项目，还可能出现互相推委
的情况。解决办法就是确定项目范围后，找到对应的业务人员，确定原始需求文档中不确定的业务规则，并和最终用户解释项目范围，不是每个需求都能随时变
更。最后是完善调研文档，由项目负责方确认。
2。设计阶段。设计阶段容易忽略项目要求和实际设计技术是否完全吻合。如果这个有所忽略，会造成比较严重的技术性后果。
3。开发阶段，这个阶段容易忽略分工和责任以及版本管理。如果是TL去负责相关文档，那么要使具体开发人员的相关信息和TL一致，开发人员需要参与开发
文档的一部分，需求变更时，开发人员必须要得到有效的通知。
4。测试阶段，这个阶段容易忽略测试细节，漏掉测试内容。这个阶段需要业务和相关数据模型熟悉的人参与，并审核测试结果。
5。实施阶段，这个阶段容易忽略实施细节文档，在实施上线的时候，由于是环境的迁移，细节决定一切。同时需要注意客户使用跟踪，因为正式环境也许有测试
环境没有的陷阱。
6。维护阶段，这个阶段容易忽略需求变更和增加后必要的测试环节，需要进行一定的回归测试，以确保整体项目质量。
最后是甲方需要审核项目各阶段需要提交的内容，不然在实施阶段补充，已经来不及了。
zpdxi...@gmail.com
Mar 19, 2008, 9:52:54 AM3/19/08
to tt...@googlegroups.com
呵呵， 总结的真好， 让人受教匪浅
不过我觉的还有一点，就是要根据客户的业务能力的强弱来调整相关方针，有的时候某些行业中的某些企业团体业务能力还真是不太强的。
当然innovate511大哥文章开头就提到了“龙头企业”，这种客户的业务能力想必是相当强的。
另外，多家单位合作的项目确实比较难， 又不好每次都请领导老大出面维持，
这种情况一般还是通过客户向各分包商施压比较有效。
2008-03-19
发件人： innovate511
发送时间： 2008-03-19 21:25:30
收件人： ttnn BI 观点
抄送：
主题： BIDW项目容易忽略的几个重要细节总结
zpdxi...@gmail.com
Mar 19, 2008, 9:52:54 AM3/19/08
to tt...@googlegroups.com
呵呵， 总结的真好， 让人受教匪浅
不过我觉的还有一点，就是要根据客户的业务能力的强弱来调整相关方针，有的时候某些行业中的某些企业团体业务能力还真是不太强的。
当然innovate511大哥文章开头就提到了“龙头企业”，这种客户的业务能力想必是相当强的。
另外，多家单位合作的项目确实比较难， 又不好每次都请领导老大出面维持，
这种情况一般还是通过客户向各分包商施压比较有效。
2008-03-19
发件人： innovate511
发送时间： 2008-03-19 21:25:30
收件人： ttnn BI 观点
抄送：
主题： BIDW项目容易忽略的几个重要细节总结
interstage
Mar 21, 2008, 1:32:32 PM3/21/08
to ttnn BI 观点
这种经过"调研--设计--开发--测试--实施"方式的BIDW项目模式已经不适合现代企业对BI的要求了,居然还在这个模式上搞来搞去,称什么"细
节决定成败",要重视细节.上周在中移动的一个全网运营业务中,我已经否定了这个模式下全网运营业务的BI方式,我们作为运营方不应该要求IT部门和乙
方在基于这种模式下把BI做好为运营提出支撑和分析判断,这对IT部门和乙方实在不公平,"岗位的知识是无法取代",难道,我们运营方每天总结出来的岗
位知识都可以快速传导给IT部门和乙方,太搞笑了. 别整这些细节的东西来解释项目是否存在加班或者返工,你整这个细节唯一的解释就是忽悠乙方(因为你
已经是甲方了,马上变成乙方的敌人了),告诉乙方这个细节没搞好,所以你们乙方没完成了BI预期的目标,继续加班,要钱的话把这些事情做好,怎么加班了
还没达到预期,细节还是又问题,你们还要钱,叫你们老板和我谈,给我10万,外加几个MM的全套服务再说.这才是你几个重要细节总结的关键点.
可惜乙方的BIER就是这样被你忽悠了.
节决定成败",要重视细节.上周在中移动的一个全网运营业务中,我已经否定了这个模式下全网运营业务的BI方式,我们作为运营方不应该要求IT部门和乙
方在基于这种模式下把BI做好为运营提出支撑和分析判断,这对IT部门和乙方实在不公平,"岗位的知识是无法取代",难道,我们运营方每天总结出来的岗
位知识都可以快速传导给IT部门和乙方,太搞笑了. 别整这些细节的东西来解释项目是否存在加班或者返工,你整这个细节唯一的解释就是忽悠乙方(因为你
已经是甲方了,马上变成乙方的敌人了),告诉乙方这个细节没搞好,所以你们乙方没完成了BI预期的目标,继续加班,要钱的话把这些事情做好,怎么加班了
还没达到预期,细节还是又问题,你们还要钱,叫你们老板和我谈,给我10万,外加几个MM的全套服务再说.这才是你几个重要细节总结的关键点.
可惜乙方的BIER就是这样被你忽悠了.
tosimple
Mar 21, 2008, 11:53:04 PM3/21/08
to ttnn BI 观点
调研阶段漫无目的
我觉得漫无目的，是因为不知道怎么去调研，要了解什么东西。
大家来讨论下调研阶段应该了解什么东西？ 要能形成一个调研模板，也不错！
我觉得漫无目的，是因为不知道怎么去调研，要了解什么东西。
大家来讨论下调研阶段应该了解什么东西？ 要能形成一个调研模板，也不错！
innovate511
Mar 22, 2008, 10:02:13 AM3/22/08
to ttnn BI 观点
阁下上次说已经脱离BI了吧，应该说搞业务管理搞多了吧，还是去重返BI研究下基础性问题再说吧
BI的基础还是数据仓库，不知道阁下理解能有几分，如果一个公司的BI系统空手起家，数据体系还比较混沌，不知道BI能做出什么混乱的数据来。我现在没
兴趣搞信息化最早的电信银行了，搞的是传统行业，这些公司ERP才没上几年，他们也希望BI能帮他们找出些流程问题。如果按照有的人的说法，直接上来说
什么流程，没足够数据做支持，谁会去支持，作为公司新成员，又算得了老几？大家都承认循序渐进循序渐进，如果连第一个BI项目还没用起来，就开始忽悠
了，总得拿点东西出来吧？
每一个项目立项，那么这个项目本身就是一个软件工程范畴了，如果没有这些基本流程，还谈什么系统开发？直接跟业务部门去忽悠，太强了吧，看来世上只有一
个达人能行。
>
> - 显示引用的文字 -
innovate511
Mar 22, 2008, 10:09:28 AM3/22/08
to ttnn BI 观点
调研这个事情本身就很虚，谁说在一个项目中就要达到把所有能想到呢，业务部门可能很多东西还没想出来，也许有的分析方法也没确定，这个时候是不是就要强
拿一个先进分析理念在项目里呢？所以我在另外一个主题写出来后台数据仓库规划，有了数据，有了规划，有了新的分析思路，咱再立一个项目去做就是了，但这
个时候有了后台数据的支持，花费、工期都会明显缩短，且数据质量也有了保证。
拿一个先进分析理念在项目里呢？所以我在另外一个主题写出来后台数据仓库规划，有了数据，有了规划，有了新的分析思路，咱再立一个项目去做就是了，但这
个时候有了后台数据的支持，花费、工期都会明显缩短，且数据质量也有了保证。
innovate511
Mar 24, 2008, 11:16:39 AM3/24/08
to ttnn BI 观点
现在先简单介绍下设计阶段。这个阶段也是我们容易忽略的地方，因为以往项目都是从ODS-DW-DM-CUBE/REPORT，只是根据情况，再在遇到
具体困难后，再做些具体的设计调整，有时甚至开发过程中再做些设计调整。
我在另外一个帖子中写到过规划，有人说很理论化，其实不是，理论书上有从这些角度去看数据仓库的么？在设计中，不要说中长期规划的远见，至少得有一个项
目范围内的预见吧？所以我一直不鼓励刚毕业的或者经验少的去直接设计商业项目，那样不但设计不出合理的项目，反而让他们的经验引向不合理的方向。
设计方面，前端BI主要看客户的需求，因为客户直接使用前端来实现BI。那么这里主要说数据仓库，没最终用户关心你后台架构怎么设计，只关心你怎么把
BI做得更好用，更可靠。如果说客户更需要你帮他们用BI实现更多价值，那你说的应该是已经有成熟数据仓库架构的成熟项目，不在本主题讨论范围，如果客
户连你的BI都不够信任，觉得不好使，后期的BI思想再好，又有什么用呢？
目前多数商业项目是从BI主题（也就是业务主导）引导数据仓库建设，技术主导的项目属于少数。这里以业务主导为例。业务主导的主要特点是需要较快见效，
最终用户为主导方向，也是甲方考核方向。所以需要以合理的时间和投入去建设BI以及数据仓库，同时也考虑多个主题的统一性，以及使用效率问题，对于高价
值数据，还需要自定义行级别的数据安全管理。当然理性的客户，最终还是会接受，在未来的规划中，范式建模的数据仓库的重要性。但他们的特点是想先产出效
果，老板才能拍板再继续不断投资建设，于是你就不能强制推行Inmon先生主导的EDW，否则完成不了项目，自己就兜着吧。
那么这个时候主要几个要点，一是是否有统一维度建模（如果是某部门独立建的集市项目，那就不必了），是否模型中不但支持业务变化，还支持业务组织结构变
化（如原来销售区域分3层，现在分4层，有结构交叉了）。在ETL方面是否有合理的增量抽取方案，每个包是否都有统一的检查流程，每个ETL过程是否有
数据验证功能。模型设计中，PK，FK是否都设计合理。是否预测到数据量会带来架构瓶颈。而对于客户的合理的需求变更，数据集市是否有足够的变化空间，
不要只有聚合汇总数据吧。
经常会碰到的项目开发中修改设计架构，往往就是对困难的估计不足，架构灵活空间太小，所以开头说的，如果设计偏差太大，后果不堪设想，会导致开发改变，
重新测试，难免会顾此失彼，而且时间被严重浪费。后台设计空间要足够大，数据集市主要考虑功能，效率不是最大的问题，正常运行好几年的项目，一般数据集
市都重组过2、3次了，效率问题每次重组后就不是问题了，如果说是空间换效率，那么数据集市相比数据仓库的数据量，应该不是大的问题。
具体困难后，再做些具体的设计调整，有时甚至开发过程中再做些设计调整。
我在另外一个帖子中写到过规划，有人说很理论化，其实不是，理论书上有从这些角度去看数据仓库的么？在设计中，不要说中长期规划的远见，至少得有一个项
目范围内的预见吧？所以我一直不鼓励刚毕业的或者经验少的去直接设计商业项目，那样不但设计不出合理的项目，反而让他们的经验引向不合理的方向。
设计方面，前端BI主要看客户的需求，因为客户直接使用前端来实现BI。那么这里主要说数据仓库，没最终用户关心你后台架构怎么设计，只关心你怎么把
BI做得更好用，更可靠。如果说客户更需要你帮他们用BI实现更多价值，那你说的应该是已经有成熟数据仓库架构的成熟项目，不在本主题讨论范围，如果客
户连你的BI都不够信任，觉得不好使，后期的BI思想再好，又有什么用呢？
目前多数商业项目是从BI主题（也就是业务主导）引导数据仓库建设，技术主导的项目属于少数。这里以业务主导为例。业务主导的主要特点是需要较快见效，
最终用户为主导方向，也是甲方考核方向。所以需要以合理的时间和投入去建设BI以及数据仓库，同时也考虑多个主题的统一性，以及使用效率问题，对于高价
值数据，还需要自定义行级别的数据安全管理。当然理性的客户，最终还是会接受，在未来的规划中，范式建模的数据仓库的重要性。但他们的特点是想先产出效
果，老板才能拍板再继续不断投资建设，于是你就不能强制推行Inmon先生主导的EDW，否则完成不了项目，自己就兜着吧。
那么这个时候主要几个要点，一是是否有统一维度建模（如果是某部门独立建的集市项目，那就不必了），是否模型中不但支持业务变化，还支持业务组织结构变
化（如原来销售区域分3层，现在分4层，有结构交叉了）。在ETL方面是否有合理的增量抽取方案，每个包是否都有统一的检查流程，每个ETL过程是否有
数据验证功能。模型设计中，PK，FK是否都设计合理。是否预测到数据量会带来架构瓶颈。而对于客户的合理的需求变更，数据集市是否有足够的变化空间，
不要只有聚合汇总数据吧。
经常会碰到的项目开发中修改设计架构，往往就是对困难的估计不足，架构灵活空间太小，所以开头说的，如果设计偏差太大，后果不堪设想，会导致开发改变，
重新测试，难免会顾此失彼，而且时间被严重浪费。后台设计空间要足够大，数据集市主要考虑功能，效率不是最大的问题，正常运行好几年的项目，一般数据集
市都重组过2、3次了，效率问题每次重组后就不是问题了，如果说是空间换效率，那么数据集市相比数据仓库的数据量，应该不是大的问题。
Qing
Mar 24, 2008, 11:23:15 PM3/24/08
to tt...@googlegroups.com
在国内做架构还真是一条充满重重险恶的征途。
干脆还是叫架构吧，别叫规划了，后者摊子太大。你看，其实大家都心知肚明，最终用户是"目光短浅"的，他们希望看到立即效果。但矛盾之处在于，数据仓库的立即效果根本看不到。所以，我想innovate其实是倾向kimball的路线。
这似乎是一种被迫的选择，是一种架构的妥协似的，当然，我觉得对于架构者来说是冷静的选择。
当然，这事儿如果站在interstage这样的管理、业务角度，是倾向于"不用架构"，直捣黄龙，达到目的就成。对此，不得不说直接达到目的的行为能够得到好的回报，不仅是物质上，甚至是精神上的。在很久以前，曾经将这两类行为分成"外"和"内"，"外"，以目的导向；"内"，无目的，追求规律。
"外"人，他的行为是短暂的冒险，而"内"人，是长久的对抗。很显然，短暂的冒险是能够给人带来更大的快乐，而长久对抗，能够产生更大价值。
说这个有些跑题。还是回到innovate的架构问题上来。
上次有个兄弟说，你这个规划最后不就是出来一种通用的什么东西么？对此，我有个回答。通用的东西，如果使用kimball的架构模式，那么他那里有比较通用的，在技术环节，很多问题都已经给你考虑。当然，这些还可以继续通用化。而在企业中实际架构，除了让这套架构贯彻下去之外，还得根据企业自己的环境进行裁剪。这功夫，也挺难。
在细节方面，我说不上太多的话，还是听innovate继续说。
另：to innovate，能不能用电子邮件回复帖子，你的帖子比较长，在web上回复的帖子经常有短行，看着很累。（虽然这是group的问题）
innovate511
Mar 25, 2008, 8:43:32 AM3/25/08
to ttnn BI 观点
不好意思，我习惯了直接web方式发帖。
所以我觉得有的BIer太注意BI的短期效应，这点不符合客户的长期效应，要知道甲方每年都会投资上千万，如果搁1、2年来一个推倒重来，架构每次都简
单易用，那么到了一定积累，每年浪费的投资都会上千万，而且每次项目的数据质量都没积累，其效果还无法预期。同时主题积累多了，如果新上来的架构，在某
个已存在的主题上有严重的数据质量问题，以前积累的客户满意度将低落到极点。所以短视的对待数据仓库，基于在BI分析上做出成绩，在客户长远发展上看，
是非常可怕的。
国内做架构风险肯定有的，不过这次我衡量了下风险，可以循序渐进，有高层亲自支持，同时公司的目的并非一步到位建好完整的架构，而是立一个方向，然后结
合公司现实，大老板要求每年见到短期效果，我们决定每年一边建新主题，一边朝着完整的架构，一步一步去完善。比如数据仓库的范式模型，这个需要将来专门
有模型团队去建设，那时候大老板已经看到了BI的效果，才能得到更大的投资，而非现在就去建设。
相信随着信息化的发展，我们现在经历的过程，在以后会得到一定的推广，那就是一边看到BI的短期效果，一边筹建上等架构，筹建长期效果。所以建议团队里
需要有BI业务分析专家，也要有精于技术架构的人，同时得到高层支持，而不是一个偏向某种模式的人主导。、
中庸之道还是更符合国情，两边都要抓，都要硬，只是某些时候看个轻重缓急吧。
On 3月25日, 上午11时23分, Qing <happys...@gmail.com> wrote:
> 在国内做架构还真是一条充满重重险恶的征途。
>
所以我觉得有的BIer太注意BI的短期效应，这点不符合客户的长期效应，要知道甲方每年都会投资上千万，如果搁1、2年来一个推倒重来，架构每次都简
单易用，那么到了一定积累，每年浪费的投资都会上千万，而且每次项目的数据质量都没积累，其效果还无法预期。同时主题积累多了，如果新上来的架构，在某
个已存在的主题上有严重的数据质量问题，以前积累的客户满意度将低落到极点。所以短视的对待数据仓库，基于在BI分析上做出成绩，在客户长远发展上看，
是非常可怕的。
国内做架构风险肯定有的，不过这次我衡量了下风险，可以循序渐进，有高层亲自支持，同时公司的目的并非一步到位建好完整的架构，而是立一个方向，然后结
合公司现实，大老板要求每年见到短期效果，我们决定每年一边建新主题，一边朝着完整的架构，一步一步去完善。比如数据仓库的范式模型，这个需要将来专门
有模型团队去建设，那时候大老板已经看到了BI的效果，才能得到更大的投资，而非现在就去建设。
相信随着信息化的发展，我们现在经历的过程，在以后会得到一定的推广，那就是一边看到BI的短期效果，一边筹建上等架构，筹建长期效果。所以建议团队里
需要有BI业务分析专家，也要有精于技术架构的人，同时得到高层支持，而不是一个偏向某种模式的人主导。、
中庸之道还是更符合国情，两边都要抓，都要硬，只是某些时候看个轻重缓急吧。
On 3月25日, 上午11时23分, Qing <happys...@gmail.com> wrote:
> 在国内做架构还真是一条充满重重险恶的征途。
>
Reply all
Reply to author
Forward
0 new messages