BI, 如何做需求分析
191 views
Skip to first unread message
Solo Zhu
Jun 12, 2008, 10:10:57 AM6/12/08
to ttnn BI 观点
BI 如何做需求分析
BI如果当作一个project的话，是和其他系统不同的系统，这样说吧，我们知道MIS,知道ERP，知道GIS等等，这些系统在管理限制上有很多的
冲突，管理和被管理，开放和限制等等，然而BI在开始就不是这样的。BI要求的就是易用还要易于扩展，首先是报表，这个是你无条件的需要去做的，其次是
adhoc和analysis，同样的岗位有不同的需求，这不是权限，管理等等的需要，而是一种习惯。就像家里做饭的那个人一样，5个人就有6种口
味。
实施BI project的时候，我们经常遇到这样的情况：
1：花少量的时间去理解客户的要求，比如reporting，了解一般的字段的数据出处，然后就开始data modeling，开始搭建DW，ETL
等等
2：中间出现大量的业务计算
3：客户需求修改，增加需求
4：数据不完整，数据口径不一致
5：性能底下
6：schedule delay
等等等等
然后：
1：重新调研需求，了解维度数据，实时数据，关系计算
2：修改模型，etl process，cube
3：重新设计接口
如果处理不当，我们可能会遇到一下几种情况。
1：overtime
2：rework again and again
3：restructure
4：game over
不管是哪一种，都是我们不愿意去看到的，我们没有办法去指责用户的需求对不对，应该不应该。他们是付钱了的，我们做得就是一种services，如果我
们遇到这样的问题应该怎么办了，应该怎么去分析了。或者说事前应该做一些什么样的准备了。
这其实需要一种平衡，客户需求和公司利润，当然，如果是甲方自己去做的话，那就是不满意和责罚之间去平衡了。
很多人会说当初定下来的范围边界，如果有需求重新增加的话，只能放到第二期里面去。其实这样的办法其实也是一种办法，只是可以对新的需求，有一个工作量
的评估吧。
其实我们定需求的时候可以由大到小，还要兼顾将来系统的扩展性
当前情况：
1：用户的使用习惯，包括如何分析数据，如何查找数据，如何在reporting导出数据，自己进行的处理
2：用户的使用不便之处，包括计算，查询数据，统计，甚至在EXCEL里面做的变动或者计算。
3：现有系统的权限设置。
4：数据统计时间，生成时间，归档时间，汇报时间等等
边界需求
1：确认业务边界，BI，BI，business在前面，所以我们必须先了解业务上的边界在哪里，很多公司在HR和finance都比较保密，这些都不
纳入DW/BI的范围，那我们就要确定清楚，是不是真的不纳入，如果中途纳入的话应该怎么处理。这些我们可以留下接口，将HR和finance综合在一
起。
2：确认系统边界，就是这个project包含哪些源系统，这些源系统又有什么特点，数据量，表，还有各个系统的详细描述，特点，已经相互间的逻辑关系
等等，这些东西就和我们将来做data profiling和ETL有关系了。
3：确认功能边界，就是做Ad-hoc，reporting，analysis，dashboard等等，需要这些吗，每一种的具体需求又是什么，包含
多少的量，每一种的dimension对应的又是什么，reporting的格式，数据源 ，dashboard的对应的KPI是什么等等，在查询，查
找，参看数据的时候，需要哪些功能。
权限需求
1：确认系统将来使用，开始上线和最终平稳使用时涉及到的部门，人员，还有每个人的权限
2：确认系统需要涉及到的维度，部门，时间，产品等等，往往权限是和这些维度有关系的。
3：将来如何去控制用户的访问权限，是有windows的AD控制还是ldap控制，或者用维度和用户关系表去空，考虑以后如果发生变化，时候便于维
护，如何去做一个维护权限的UI。
数据质量
1：各功能（adhoc，reporting，analysis，dashboard）涉及到的数据表结构。
2：分析各系统的数据质量，最好有数据质量报告。包括维度，空值，一致性，完整性的检查
需求记录
不管我们和用户谈到什么，只要是和系统有关系的，最好能写出报告的形式，然后再和用户讨论，谈谈你的理解，看用户是否认可，有记录，我们不一定要用户去
签字，只是为了以后我们出现人员变动或者最后做UAT测试的时候方便。
如果你真的没有时间做上面的这些事情，那你一定要做好一下的工作
1：多多了解系统各个岗位的人员的要求，不管是Ad-hoc，reporting，还是analysis，dashboard，听听他们所说什么，有什
么要求
2：分析主题，归纳需求的相似点。看看有没有统一实现的方法。
3：逐个的去完成用户的功能，记住，要一个一个的去完成，完成一个后，就和相应的人员去确认是否是他想要的。不行就again。
4：关注说话有分量的人，比如leader，mananger或者high level manager等等，多和他们沟通，或者尽量完成他们的要求，
做到他们满意。
如果还是不行的话
最后一招：告诉用户，不要付钱了。走人
特别需要提出的是：不管我们什么时候完成全部的功能，在我们能展现给用户数据的时候，尽量想办法让他们去使用，及早的发现问题，让他们多多提出问题。
在我，Solo Zhu，多年和客户打交道的时候，我们能完成的只是用户想要的30%-50%，而大多时候他们操作的时候还是需要按照老办法去处理。
其实需求分析不仅只是在项目开始的时候做，如果我们吧BI/DW的项目当作一个过程的话，每一个时间点都可可以看做是一个小项目的开始。
本文在本人blog上同步更新http://bidwhome.itpub.net/
欢迎大家谈谈自己的经历和经验
BI如果当作一个project的话，是和其他系统不同的系统，这样说吧，我们知道MIS,知道ERP，知道GIS等等，这些系统在管理限制上有很多的
冲突，管理和被管理，开放和限制等等，然而BI在开始就不是这样的。BI要求的就是易用还要易于扩展，首先是报表，这个是你无条件的需要去做的，其次是
adhoc和analysis，同样的岗位有不同的需求，这不是权限，管理等等的需要，而是一种习惯。就像家里做饭的那个人一样，5个人就有6种口
味。
实施BI project的时候，我们经常遇到这样的情况：
1：花少量的时间去理解客户的要求，比如reporting，了解一般的字段的数据出处，然后就开始data modeling，开始搭建DW，ETL
等等
2：中间出现大量的业务计算
3：客户需求修改，增加需求
4：数据不完整，数据口径不一致
5：性能底下
6：schedule delay
等等等等
然后：
1：重新调研需求，了解维度数据，实时数据，关系计算
2：修改模型，etl process，cube
3：重新设计接口
如果处理不当，我们可能会遇到一下几种情况。
1：overtime
2：rework again and again
3：restructure
4：game over
不管是哪一种，都是我们不愿意去看到的，我们没有办法去指责用户的需求对不对，应该不应该。他们是付钱了的，我们做得就是一种services，如果我
们遇到这样的问题应该怎么办了，应该怎么去分析了。或者说事前应该做一些什么样的准备了。
这其实需要一种平衡，客户需求和公司利润，当然，如果是甲方自己去做的话，那就是不满意和责罚之间去平衡了。
很多人会说当初定下来的范围边界，如果有需求重新增加的话，只能放到第二期里面去。其实这样的办法其实也是一种办法，只是可以对新的需求，有一个工作量
的评估吧。
其实我们定需求的时候可以由大到小，还要兼顾将来系统的扩展性
当前情况：
1：用户的使用习惯，包括如何分析数据，如何查找数据，如何在reporting导出数据，自己进行的处理
2：用户的使用不便之处，包括计算，查询数据，统计，甚至在EXCEL里面做的变动或者计算。
3：现有系统的权限设置。
4：数据统计时间，生成时间，归档时间，汇报时间等等
边界需求
1：确认业务边界，BI，BI，business在前面，所以我们必须先了解业务上的边界在哪里，很多公司在HR和finance都比较保密，这些都不
纳入DW/BI的范围，那我们就要确定清楚，是不是真的不纳入，如果中途纳入的话应该怎么处理。这些我们可以留下接口，将HR和finance综合在一
起。
2：确认系统边界，就是这个project包含哪些源系统，这些源系统又有什么特点，数据量，表，还有各个系统的详细描述，特点，已经相互间的逻辑关系
等等，这些东西就和我们将来做data profiling和ETL有关系了。
3：确认功能边界，就是做Ad-hoc，reporting，analysis，dashboard等等，需要这些吗，每一种的具体需求又是什么，包含
多少的量，每一种的dimension对应的又是什么，reporting的格式，数据源 ，dashboard的对应的KPI是什么等等，在查询，查
找，参看数据的时候，需要哪些功能。
权限需求
1：确认系统将来使用，开始上线和最终平稳使用时涉及到的部门，人员，还有每个人的权限
2：确认系统需要涉及到的维度，部门，时间，产品等等，往往权限是和这些维度有关系的。
3：将来如何去控制用户的访问权限，是有windows的AD控制还是ldap控制，或者用维度和用户关系表去空，考虑以后如果发生变化，时候便于维
护，如何去做一个维护权限的UI。
数据质量
1：各功能（adhoc，reporting，analysis，dashboard）涉及到的数据表结构。
2：分析各系统的数据质量，最好有数据质量报告。包括维度，空值，一致性，完整性的检查
需求记录
不管我们和用户谈到什么，只要是和系统有关系的，最好能写出报告的形式，然后再和用户讨论，谈谈你的理解，看用户是否认可，有记录，我们不一定要用户去
签字，只是为了以后我们出现人员变动或者最后做UAT测试的时候方便。
如果你真的没有时间做上面的这些事情，那你一定要做好一下的工作
1：多多了解系统各个岗位的人员的要求，不管是Ad-hoc，reporting，还是analysis，dashboard，听听他们所说什么，有什
么要求
2：分析主题，归纳需求的相似点。看看有没有统一实现的方法。
3：逐个的去完成用户的功能，记住，要一个一个的去完成，完成一个后，就和相应的人员去确认是否是他想要的。不行就again。
4：关注说话有分量的人，比如leader，mananger或者high level manager等等，多和他们沟通，或者尽量完成他们的要求，
做到他们满意。
如果还是不行的话
最后一招：告诉用户，不要付钱了。走人
特别需要提出的是：不管我们什么时候完成全部的功能，在我们能展现给用户数据的时候，尽量想办法让他们去使用，及早的发现问题，让他们多多提出问题。
在我，Solo Zhu，多年和客户打交道的时候，我们能完成的只是用户想要的30%-50%，而大多时候他们操作的时候还是需要按照老办法去处理。
其实需求分析不仅只是在项目开始的时候做，如果我们吧BI/DW的项目当作一个过程的话，每一个时间点都可可以看做是一个小项目的开始。
本文在本人blog上同步更新http://bidwhome.itpub.net/
欢迎大家谈谈自己的经历和经验
life20...@126.com
Jun 12, 2008, 11:15:29 AM6/12/08
to tt...@googlegroups.com
Solo Zhu
Jun 12, 2008, 9:04:00 PM6/12/08
to ttnn BI 观点
说得很对，其实是有点内容匮乏，没有太多的举证，但是细想想，简单的举证成为内容匮乏，写的具体，有需要介绍项目背景等等，我写出来只是抛砖引玉，希望
大家能就某个具体的问题谈下去，这样兴许会一起大家的共鸣。
> >欢迎大家谈谈自己的经历和经验- Hide quoted text -
>
> - Show quoted text -
大家能就某个具体的问题谈下去，这样兴许会一起大家的共鸣。
>
> - Show quoted text -
Qing
Jun 13, 2008, 12:45:38 AM6/13/08
to tt...@googlegroups.com
说bi的需求，其实这里很多说的是dw的需求，我觉得这两个还不太一样。dw需求大多还不是跟最终业务部门谈，很可能是it部门，bi需求要是跟it部门谈，那就糟了。
至今没有一个dw的验收标准，昨天一位朋友又开始琢磨dw的价值问题，问我以前提过的是什么，我告诉他是更快、更方便、更准确、更安全地访问数据。他说，比较虚。是啊，是虚的，但我觉得还算完整。如果能够进一步，用量化的指标来衡量这四个方面，我想就可以用来验收数据仓库项目。而dw的需求，则是约定数据源的范围，以及这四个方面指标的预期值。而在dw上支撑的应用，虽然严格来说，不属于dw范畴，但一般都会纳入dw的需求范畴（很多项目不会区分dw和bi），比如出多少张报表，出多少分析主题。用应用来验收dw是没办法的办法。
而对于bi的需求，面向决策支持。我觉得应当得设想一下他会如何改变业务上的决策流程。如果没有做到这一步，那么通常，这个需求就是一种形式的，注定要失败。
比如一张报表，如果这是每月经营分析会上需要拿来说事的报表，这个需求很明确，可以清晰地看到他影响了决策流程。但一个cube呢？一个业务人员说，我需要结合A维度和B维度观察C度量，请给我弄个cube。这是真实的需求么？还是他想当然？去了解一下这个人日常工作是不是真的关注这些维度和度量，还是他想当然地为别的业务部门考虑。这种判断需要经验，还需要一些拒绝的勇气。他要这个干什么？如果他是需要固定的分析报表，不要给他cube。去关注他要解决的问题，而不是让他说出他需要维度和度量。
solo抛出一块砖头，我这算不算玉？
solo抛出一块砖头，我这算不算玉？
另外关于写的具体就需要介绍项目背景这个说法，我想可以虚构场景，或者省略一些关键信息。
2008/6/13 Solo Zhu <solo...@gmail.com>:
说得很对，其实是有点内容匮乏，没有太多的举证，但是细想想，简单的举证成为内容匮乏，写的具体，有需要介绍项目背景等等，我写出来只是抛砖引玉，希望...
interstage
Jun 14, 2008, 10:40:00 PM6/14/08
to ttnn BI 观点
Qing说的非常对,Solo这个BI的需求分析描述,其实是我们IT人员所擅长的DW需求分析. 不是真正的BI需求分析. 那BI的需求分析是如何
被归纳出来的,又是谁来归纳的呢?
这个问题其实很难定型. 一般BI的需求分析不太可能是IT人员来做(IT能做的是DW的需求分析),一般认为应该是企业业务人员+管理者,或者是咨询
公司来做BI需求分析.
以前我们非常迷信咨询公司,但有一个笑话能说明咨询公司是可以做行业的BI需求分析的,但很难精细的做具体企业的BI需求分析:
---有一个老头，正在草地上放羊，忽然走来一个年轻人，年经人走到老头面前说：老先生，我可以为您服务，我将告诉您您的这群羊有几头，作为酬劳您需要
给我一头羊。老头还未作答，年青人就开始了工作，年轻人用笔记本电脑无线上网，链接上NASA的内部网，调动低轨道卫星，把卫星遥感成像的图片再通过软
件分析，数十分钟后，年轻人再次走到老头面前：老先生，您的羊群共有763头。说完后他抱起一只羊就要走。
---老头这时叫住了年青人：年青人，如果我能猜出你就职的公司，你可不可以把酬劳还给我？
---可以，年轻人答。 你是麦肯锡公司的，老头说。 年轻人很惊讶，您怎么知道？老头笑了：因为你具有该公司咨询人员的所有特点啊，第一、你不请自
来。第二、你告诉我的分析结果是我本就知道的。第三、你抱走的不是羊，而是我的牧羊犬
因此,我们只能非常小心的告诉要上BI项目企业,真正的BI需求分析只能是你们自己来做,因为除了你们自己没有人更了解自己的企业.于是乎,这个BI需
求分析就更难做,甲方请你来做事情,你说让甲方来做,那甲方会很不舒服的. 我的经验是这样的,仅供参考,谈不玉,也只是砖:
1,设计很多问题,不管从大到业务流程改善,小到数据库性能改善,拿着这个问题和不同部门交流,其实就是听他们诉苦(他们期望的报表)和学习他们经验
(他们现在用的报表).
2,除对IT部门诉苦,不采用任何行动外,对其他各部门所期望报表和在用的报表,从报表格式做归纳和总结,然后,把报表格式分解成管理视点和数据本身,
拿着这些管理视点再和业务部门进行交流,对已有报表和期望报表的管理视点进行定义规范,对双方未想到的管理视点进行设计规范.
3,规范完管理视点后,再拿着这个管理规范和数据本身,和IT部门进行交流,写BI/DW需求分析书,把已有报表和期望报表的管理视点进行定义,定义公
共或部门管理或个人管理视点,把可能成为管理视点的数据在DW中以元数据方式进行关联,然后设计出业务部门快速进行管理视点设计和创建的IT描述.
4,定义和设计完管理视点规范后,开始就数据本身考虑传统的DW性能模式,选择DW架构,建立拓扑,定义ETL流程,定义可能的数据CUBE,定义可能
的数据模型,是否这些数据产生需要采用数据挖掘的一些算法等等.把这些描述在需求分析中.
5,写完管理视点规范定义,以及描述完数据本身架构和界定后,再合并管理视点和数据,这时候,基本上已经不知道这个BI项目可能可以出多少张报表了,但
可以归纳出多少种业务报表,取一些通用的业务报表,在此报表基础上结合业务特点定义出规范的图形格式(饼图,柱状图等)和样式(雷达图,亲和图等).
6,最后一章,用这些通用报表和图形表示,开始从业务来阐述代表什么意思(这个其实就是一开始他们如何诉苦和经验的,你把他们零碎的交流归纳而已)
这就是,我一般做的BI需求分析,从用户的报表和图形入手,到归纳用户的报表和图形结束.中间是DW需求分析,整合起来是BI需求分析. 其实应该甲方
自己做需求分析,但一般情况下甲方不愿意做,那只有我们来回跑腿做了,只要记住一点:你要做的BI系统是为了甲方在分析和决策上变得更方便,所以原来不
方便的东西只能让项目实施商来承担了.
仅供参考,欢迎拍砖
被归纳出来的,又是谁来归纳的呢?
这个问题其实很难定型. 一般BI的需求分析不太可能是IT人员来做(IT能做的是DW的需求分析),一般认为应该是企业业务人员+管理者,或者是咨询
公司来做BI需求分析.
以前我们非常迷信咨询公司,但有一个笑话能说明咨询公司是可以做行业的BI需求分析的,但很难精细的做具体企业的BI需求分析:
---有一个老头，正在草地上放羊，忽然走来一个年轻人，年经人走到老头面前说：老先生，我可以为您服务，我将告诉您您的这群羊有几头，作为酬劳您需要
给我一头羊。老头还未作答，年青人就开始了工作，年轻人用笔记本电脑无线上网，链接上NASA的内部网，调动低轨道卫星，把卫星遥感成像的图片再通过软
件分析，数十分钟后，年轻人再次走到老头面前：老先生，您的羊群共有763头。说完后他抱起一只羊就要走。
---老头这时叫住了年青人：年青人，如果我能猜出你就职的公司，你可不可以把酬劳还给我？
---可以，年轻人答。 你是麦肯锡公司的，老头说。 年轻人很惊讶，您怎么知道？老头笑了：因为你具有该公司咨询人员的所有特点啊，第一、你不请自
来。第二、你告诉我的分析结果是我本就知道的。第三、你抱走的不是羊，而是我的牧羊犬
因此,我们只能非常小心的告诉要上BI项目企业,真正的BI需求分析只能是你们自己来做,因为除了你们自己没有人更了解自己的企业.于是乎,这个BI需
求分析就更难做,甲方请你来做事情,你说让甲方来做,那甲方会很不舒服的. 我的经验是这样的,仅供参考,谈不玉,也只是砖:
1,设计很多问题,不管从大到业务流程改善,小到数据库性能改善,拿着这个问题和不同部门交流,其实就是听他们诉苦(他们期望的报表)和学习他们经验
(他们现在用的报表).
2,除对IT部门诉苦,不采用任何行动外,对其他各部门所期望报表和在用的报表,从报表格式做归纳和总结,然后,把报表格式分解成管理视点和数据本身,
拿着这些管理视点再和业务部门进行交流,对已有报表和期望报表的管理视点进行定义规范,对双方未想到的管理视点进行设计规范.
3,规范完管理视点后,再拿着这个管理规范和数据本身,和IT部门进行交流,写BI/DW需求分析书,把已有报表和期望报表的管理视点进行定义,定义公
共或部门管理或个人管理视点,把可能成为管理视点的数据在DW中以元数据方式进行关联,然后设计出业务部门快速进行管理视点设计和创建的IT描述.
4,定义和设计完管理视点规范后,开始就数据本身考虑传统的DW性能模式,选择DW架构,建立拓扑,定义ETL流程,定义可能的数据CUBE,定义可能
的数据模型,是否这些数据产生需要采用数据挖掘的一些算法等等.把这些描述在需求分析中.
5,写完管理视点规范定义,以及描述完数据本身架构和界定后,再合并管理视点和数据,这时候,基本上已经不知道这个BI项目可能可以出多少张报表了,但
可以归纳出多少种业务报表,取一些通用的业务报表,在此报表基础上结合业务特点定义出规范的图形格式(饼图,柱状图等)和样式(雷达图,亲和图等).
6,最后一章,用这些通用报表和图形表示,开始从业务来阐述代表什么意思(这个其实就是一开始他们如何诉苦和经验的,你把他们零碎的交流归纳而已)
这就是,我一般做的BI需求分析,从用户的报表和图形入手,到归纳用户的报表和图形结束.中间是DW需求分析,整合起来是BI需求分析. 其实应该甲方
自己做需求分析,但一般情况下甲方不愿意做,那只有我们来回跑腿做了,只要记住一点:你要做的BI系统是为了甲方在分析和决策上变得更方便,所以原来不
方便的东西只能让项目实施商来承担了.
仅供参考,欢迎拍砖
Solo Zhu
Jun 15, 2008, 9:51:35 PM6/15/08
to ttnn BI 观点
Good, 说的很对
其实BI是企业的一种战略 ，而DW是一种过程，一种战术。
BI有两种理解：一种是客户层面的商业智能，包括策略与管理，一种是技术层面的企业应用，具体归结为前端的展示。
也许我的标题让大家误会了。
其实BI/DW其实很多企业和公司都放在一起，作为技术应用，我不会去建议客户，BI到底应该怎么做，因为每个人的理解不一样。其实给你一个容器，这个
东西像碗一样，比碗大一点点。那么张三说是碗，李四说是盆，王五说是锅。你说到底是什么了。
言归正传，我要说的其实就是在实施项目前，应该让需求分析很好的和构架结合在一起。提出来的很多问题不是什么理想化的东西，而是一种和客户接触时有张有
弛的方式。
我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简
单。
还有就是我们在这里可以多谈谈做需求分析的东西，我觉得做好需求，是技术构架之外的最重要的东西，也是整个项目的目标，我们只有找好目标，才能做好项
目，否则一切都是白费劲。
其实BI是企业的一种战略 ，而DW是一种过程，一种战术。
BI有两种理解：一种是客户层面的商业智能，包括策略与管理，一种是技术层面的企业应用，具体归结为前端的展示。
也许我的标题让大家误会了。
其实BI/DW其实很多企业和公司都放在一起，作为技术应用，我不会去建议客户，BI到底应该怎么做，因为每个人的理解不一样。其实给你一个容器，这个
东西像碗一样，比碗大一点点。那么张三说是碗，李四说是盆，王五说是锅。你说到底是什么了。
言归正传，我要说的其实就是在实施项目前，应该让需求分析很好的和构架结合在一起。提出来的很多问题不是什么理想化的东西，而是一种和客户接触时有张有
弛的方式。
我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简
单。
还有就是我们在这里可以多谈谈做需求分析的东西，我觉得做好需求，是技术构架之外的最重要的东西，也是整个项目的目标，我们只有找好目标，才能做好项
目，否则一切都是白费劲。
Solo Zhu
Jun 15, 2008, 10:00:50 PM6/15/08
to ttnn BI 观点
并不是所有的客户真正理解BI，其实很多的应用都是建立在report之上的，分析和挖掘只是一些比较有高技术的东西。
在经常和客户的交流中，我体会到一点就是我们和业务人员交流时，尽量不要使用技术词汇，特别是难以理解的，而且他们很厌烦。在沟通中经常会中断或者不了
了之。如果你觉得有用，你可以给客户看看，他有兴趣他自然会问的，你再慢慢解释。
BI的理解也是这样的。
而且在需求分析阶段，我们尽量的去听，去体会。
在经常和客户的交流中，我体会到一点就是我们和业务人员交流时，尽量不要使用技术词汇，特别是难以理解的，而且他们很厌烦。在沟通中经常会中断或者不了
了之。如果你觉得有用，你可以给客户看看，他有兴趣他自然会问的，你再慢慢解释。
BI的理解也是这样的。
而且在需求分析阶段，我们尽量的去听，去体会。
Qing
Jun 15, 2008, 10:14:56 PM6/15/08
to tt...@googlegroups.com
这个观点我不认同。
BI项目如果不涉及客户管理方式的改变，我认为就是失败，这也是我们目前很多bi项目的现状。当然，说这完全是集成商的责任当然有点冤枉。对于客户，改变管理方式不是通过上一个系统，但上一个系统是为了优化管理。如果客户自己也没有明白（很正常的事情）为什么要上这个系统，而集成商、咨询商也不说上这个系统能够产生什么样的改变。那肯定是失败无疑。
2008/6/16 Solo Zhu <solo...@gmail.com>:
.. 我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简单...
Solo Zhu
Jun 15, 2008, 10:34:51 PM6/15/08
to ttnn BI 观点
呵呵，求同存异吧
我刚才说了，每个人的理解不一样，对BI的，BI项目的。
我不知道report的应用，算不算BI， 什么样的管理方式又算是BI的管理方式了
BI项目需要客户的管理方式怎么去改变了？
难道企业的管理方式都需要遵循BI的方式去做吗？
其实我一直有一个观点：IT本身给企业带来不了利润，只能方便管理。IT只能去适应业务，坚决不能要业务来适应IT。如果业务发生改变，那是管理的需
要，不是IT所带来的。
我刚才说了，每个人的理解不一样，对BI的，BI项目的。
我不知道report的应用，算不算BI， 什么样的管理方式又算是BI的管理方式了
BI项目需要客户的管理方式怎么去改变了？
难道企业的管理方式都需要遵循BI的方式去做吗？
其实我一直有一个观点：IT本身给企业带来不了利润，只能方便管理。IT只能去适应业务，坚决不能要业务来适应IT。如果业务发生改变，那是管理的需
要，不是IT所带来的。
hunter
Jun 16, 2008, 9:10:10 AM6/16/08
to ttnn BI 观点
以前看一个什么管理大师的文章，说产品创新难以构成企业的长期战略优势，因为长远来看这些创新总会被别人赶上。最重要的应该还是内功，包括流程，管理和
战略定位。似乎也暗合最近看到的一个对CEO的调查结果：90%以上认同IT创新（我理解就是流程了）对企业非常重要。
战略定位。似乎也暗合最近看到的一个对CEO的调查结果：90%以上认同IT创新（我理解就是流程了）对企业非常重要。
interstage
Jun 16, 2008, 10:40:16 AM6/16/08
to ttnn BI 观点
让集成商要说明系统能优化企业管理这个要求,对于目前中国集成商来说,太难了.咨询商的确应该有这个能力,但咨询商一般给出行业经验和通用的系统,很多
情况下给出的系统是不适合该企业的管理要求,更谈不上优化. 记得去年有篇文章是SONY的副社长写的"绩效管理毁了SONY",连一度神话化的企业
SONY在上BI系统都会失误,我们又能太苛求集成商和咨询商什么呢.
我们不能太吹嘘BI系统对企业管理的神奇之处(这是目前BIER最过度自信,也是我前期一直打击的),但也不要一下子对BI系统太不以为然,它是企
业决策中的一种分析手段和方法,而且很多东西值得我们学习.
我个人认为关键在于互动,如果通过BI系统,建立起企业数据和企业决策的互动机制,流程,平台,这就足够了.
> BI项目如果不涉及客户管理方式的改变，我认为就是失败，这也是我们目前很多bi项目的现状。当然，说这完全是集成商的责任当然有点冤枉。对于客户，改变管理方-式不是通过上一个系统，但上一个系统是为了优化管理。如果客户自己也没有明白（很正常的事情）为什么要上这个系统，而集成商、咨询商也不说上这个系统能够产生什-么样的改变。那肯定是失败无疑。
>
> 2008/6/16 Solo Zhu <solof...@gmail.com>:
>
>
>
>
>
> > .. 我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简单...- 隐藏被引用文字 -
>
> - 显示引用的文字 -
情况下给出的系统是不适合该企业的管理要求,更谈不上优化. 记得去年有篇文章是SONY的副社长写的"绩效管理毁了SONY",连一度神话化的企业
SONY在上BI系统都会失误,我们又能太苛求集成商和咨询商什么呢.
我们不能太吹嘘BI系统对企业管理的神奇之处(这是目前BIER最过度自信,也是我前期一直打击的),但也不要一下子对BI系统太不以为然,它是企
业决策中的一种分析手段和方法,而且很多东西值得我们学习.
我个人认为关键在于互动,如果通过BI系统,建立起企业数据和企业决策的互动机制,流程,平台,这就足够了.
> BI项目如果不涉及客户管理方式的改变，我认为就是失败，这也是我们目前很多bi项目的现状。当然，说这完全是集成商的责任当然有点冤枉。对于客户，改变管理方-式不是通过上一个系统，但上一个系统是为了优化管理。如果客户自己也没有明白（很正常的事情）为什么要上这个系统，而集成商、咨询商也不说上这个系统能够产生什-么样的改变。那肯定是失败无疑。
>
> 2008/6/16 Solo Zhu <solof...@gmail.com>:
>
>
>
>
>
> > .. 我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简单...- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Solo Zhu
Jun 16, 2008, 9:40:11 PM6/16/08
to ttnn BI 观点
是的，在于互动，互动很重要，但是也需要边界和范围，如果是甲乙方的关系的话，就更重要。至于企业数据和决策的互动机制，我倒是有点费解。
其实大家也都知道咨询商是什么角色了，其实就和导购，导游一样，你不知道的时候，他们是救星，你知道的时候，你就会觉得自己花钱太容易了。
还有就是很多咨询公司都是从业务入手的，但是业务本身是需要符合企业习惯的，有企业自身特色的，我没有见过几个咨询公司把项目做得很成功，倒是经常听说
咨询公司比较会忽悠人。
On Jun 16, 10:40 pm, interstage <buer0...@gmail.com> wrote:
> 让集成商要说明系统能优化企业管理这个要求,对于目前中国集成商来说,太难了.咨询商的确应该有这个能力,但咨询商一般给出行业经验和通用的系统,很多
> 情况下给出的系统是不适合该企业的管理要求,更谈不上优化. 记得去年有篇文章是SONY的副社长写的"绩效管理毁了SONY",连一度神话化的企业
> SONY在上BI系统都会失误,我们又能太苛求集成商和咨询商什么呢.
> 我们不能太吹嘘BI系统对企业管理的神奇之处(这是目前BIER最过度自信,也是我前期一直打击的),但也不要一下子对BI系统太不以为然,它是企
> 业决策中的一种分析手段和方法,而且很多东西值得我们学习.
> 我个人认为关键在于互动,如果通过BI系统,建立起企业数据和企业决策的互动机制,流程,平台,这就足够了.
>
> On 6月16日, 上午10时14分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 这个观点我不认同。
>
> > BI项目如果不涉及客户管理方式的改变，我认为就是失败，这也是我们目前很多bi项目的现状。当然，说这完全是集成商的责任当然有点冤枉。对于客户，改变管理方--式不是通过上一个系统，但上一个系统是为了优化管理。如果客户自己也没有明白（很正常的事情）为什么要上这个系统，而集成商、咨询商也不说上这个系统能够产生-什-么样的改变。那肯定是失败无疑。
其实大家也都知道咨询商是什么角色了，其实就和导购，导游一样，你不知道的时候，他们是救星，你知道的时候，你就会觉得自己花钱太容易了。
还有就是很多咨询公司都是从业务入手的，但是业务本身是需要符合企业习惯的，有企业自身特色的，我没有见过几个咨询公司把项目做得很成功，倒是经常听说
咨询公司比较会忽悠人。
On Jun 16, 10:40 pm, interstage <buer0...@gmail.com> wrote:
> 让集成商要说明系统能优化企业管理这个要求,对于目前中国集成商来说,太难了.咨询商的确应该有这个能力,但咨询商一般给出行业经验和通用的系统,很多
> 情况下给出的系统是不适合该企业的管理要求,更谈不上优化. 记得去年有篇文章是SONY的副社长写的"绩效管理毁了SONY",连一度神话化的企业
> SONY在上BI系统都会失误,我们又能太苛求集成商和咨询商什么呢.
> 我们不能太吹嘘BI系统对企业管理的神奇之处(这是目前BIER最过度自信,也是我前期一直打击的),但也不要一下子对BI系统太不以为然,它是企
> 业决策中的一种分析手段和方法,而且很多东西值得我们学习.
> 我个人认为关键在于互动,如果通过BI系统,建立起企业数据和企业决策的互动机制,流程,平台,这就足够了.
>
> On 6月16日, 上午10时14分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 这个观点我不认同。
>
>
> > 2008/6/16 Solo Zhu <solof...@gmail.com>:
>
> > > .. 我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简单...- 隐藏被引用文字 -
>
> > - 显示引用的文字 -- Hide quoted text -
> > 2008/6/16 Solo Zhu <solof...@gmail.com>:
>
> > > .. 我认为项目不应该涉及到客户管理方式的改变，除非是他们自己发现，而且需要改，必须改的东西。不管是对还是错，改变管理方式，不是上一个系统这么简单...- 隐藏被引用文字 -
>
袁旭
Jun 17, 2008, 12:26:48 AM6/17/08
to tt...@googlegroups.com
Goldenfish3
Jun 17, 2008, 6:22:22 AM6/17/08
to tt...@googlegroups.com
企业数据和管理决策的互动，关键是谁先走出第一步，让这个互动能真的“动”起来。
2008-06-17
Goldenfish3
发件人： interstage
发送时间： 2008-06-16 22:40:34
收件人： ttnn BI 观点
抄送：
主题： Re: BI, 如何做需求分析
贺小毅
Jun 17, 2008, 9:56:15 PM6/17/08
to tt...@googlegroups.com
想跳跳了，大家给推荐推荐啊
Reply all
Reply to author
Forward
0 new messages