也谈业务建模和数据建模
Jerome Qi
我把业务建模和数据建模的关系理一下，这样争论也有个基础。当然其中肯定也有不当之处，请多多指点。
先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角等信息用计算机的语言表示出来。
这两类建模从方法到目的都是不同的。
第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比重等等内容，这些是业务人员需要完成的工作，有大量的领域知识在里面。这部分建模的结果有些会反映到信息系统中，有些就只是咨询，反映到用户的日常工作中。
第二类，是对企业业务状况的描述，如贷款和抵押品之间是什么关系，与抵押品相关的信息都有那些、产品内部的层级关系，用户分析问题的业务视角等等，这些内容需要业务人员和信息人员共同参与完成，最终体现在信息系统之中也就是开发人员使用的数据表。
对于KPI的建模是属于第一类业务建模，它的重点在于哪些因素会影响KPI，影响的比重有多大。但是计算KPI需要的因素以及对这些因素的数据需求都属于第二类业务建模。
再说数据建模，数据建模也分为两个步骤，第一类是逻辑模型，第二类是物理模型。
这两类模型的差别并不是很大。
第一类，逻辑模型，也称为实体关系模型（维度建模可以认为是实体关系建模中的一种），是用计算机术语表示出来的业务状况以及业务分析视角。事实上，逻辑模型就是前面提到的第二类业务模型。我们是做信息系统的，所作的东西最终都是要体现在计算机里，所以，第二类业务模型和数据模型之间的距离并不大。
第二类，物理模型，是将逻辑模型转化成的物理表，这里会出于性能、效率和易用性等考虑对逻辑模型做一些处理。这些处理在逻辑模型中也存在。将逻辑模型转化为物理模型需要DBA的参与。
而我们在日常工作中提到的业务建模一般是指第一类业务建模，即从业务的角度来设计KPI等内容。
我们在日常工作中提到的数据建模一般是指第二类业务建模，也是第一类数据建模。这两类原本就是同一份工作。也许有很牛的公司会将这两部分分开，请完全不懂技术的业务专家来设计这部分。但大部分情况下这部分是需要业务和技术都懂的人来完成。我理解innovate511提到的数据建模应该是这类和业务也直接相关的建模，而不是纯数据的建模。（请innovate511确认。）
我们再看DW和BI，一般DW里不会有第一类业务模型，但是一定会有第一类业务模型需要的数据，也可能有第一类业务模型分析的结果。而BI里可能有第一类业务模型，也可能没有第一类业务模型，例如对数据进行OLAP分析就不一定有第一类业务模型。但是勿庸置疑的是，无论是DW还是BI，它的目的都是为业务服务的。所以说业务驱动BI、DW或者说需求驱动BI、DW都是一定的。但是归根到底，DW和BI都是用来辅助分析的，真正提高企业效益的是使用DW和BI的分析人员。从非技术层面来促进BI成功我的感觉更像是借助BI来提出的管理咨询，而不是信息技术咨询。
随便谈几句，欢迎指导。
--
此事古难全
raullew
全民BI那等于大家都不要做了，告诉客户老总说，你们的企业管理方式错了，要这样这样搞，其实这不是搞BI，而是搞管理咨询了。事实上这种做法在甲方自
身没有什么执行力，混日子的员工懒得理你，分析人员自有自己的分析方法不干BI的事情，剩下的想要看数据的业务人员肯定是要求助于IT来整理数据，但按
道理乙方又不做实施，于是成了空对空。所以这样的consultant还是去麦肯锡吧，不要来趟BI这个浑水了
On 6月21日, 下午2时10分, "Jerome Qi" <ston...@gmail.com> wrote:
> 最近工作比较忙，一直在TTNN潜水，看到大家在讨论业务建模和数据建模，我也一直做这个方向，很感兴趣。
> 我把业务建模和数据建模的关系理一下，这样争论也有个基础。当然其中肯定也有不当之处，请多多指点。
>
> 先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角 等信息用计算机的语言表示出来。
> 这两类建模从方法到目的都是不同的。
> 第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比重等等内容，这些是业务人员需要完成的工作，有大量的领域 知识在里面。这部分建模的结果有些会反映到信息系统中，有些就只是咨询，反映到用户的日常工作中。
> 第二类，是对企业业务状况的描述，如贷款和抵押品之间是什么关系，与抵押品相关的信息都有那些、产品内部的层级关系，用户分析问题的业务视角等等，这些内容需要 业务人员和信息人员共同参与完成，最终体现在信息系统之中也就是开发人员使用的数据表。
>
> 对于KPI的建模是属于第一类业务建模，它的重点在于哪些因素会影响KPI，影响的比重有多大。但是计算KPI需要的因素以及对这些因素的数据需求都属于第二类 业务建模。
>
> 再说数据建模，数据建模也分为两个步骤，第一类是逻辑模型，第二类是物理模型。
> 这两类模型的差别并不是很大。
> 第一类，逻辑模型，也称为实体关系模型（维度建模可以认为是实体关系建模中的一种），是用计算机术语表示出来的业务状况以及业务分析视角。事实上，逻辑模型就是 前面提到的第二类业务模型。我们是做信息系统的，所作的东西最终都是要体现在计算机里，所以，第二类业务模型和数据模型之间的距离并不大。
> 第二类，物理模型，是将逻辑模型转化成的物理表，这里会出于性能、效率和易用性等考虑对逻辑模型做一些处理。这些处理在逻辑模型中也存在。将逻辑模型转化为物理 模型需要DBA的参与。
>
> 而我们在日常工作中提到的业务建模一般是指第一类业务建模，即从业务的角度来设计KPI等内容。
> 我们在日常工作中提到的数据建模一般是指第二类业务建模，也是第一类数据建模。这两类原本就是同一份工作。也许有很牛的公司会将这两部分分开，请完全不懂技术的 业务专家来设计这部分。但大部分情况下这部分是需要业务和技术都懂的人来完成。我理解innovate511提到的数据建模应该是这类和业务也直接相关的建模， 而不是纯数据的建模。（请innovate511确认。）
>
> 我们再看DW和BI，一般DW里不会有第一类业务模型，但是一定会有第一类业务模型需要的数据，也可能有第一类业务模型分析的结果。而BI里可能有第一类业务模 型，也可能没有第一类业务模型，例如对数据进行OLAP分析就不一定有第一类业务模型。但是勿庸置疑的是，无论是DW还是BI，它的目的都是为业务服务的。所以 说业务驱动BI、DW或者说需求驱动BI、DW都是一定的。但是归根到底，DW和BI都是用来辅助分析的，真正提高企业效益的是使用DW和BI的分析人员。从非 技术层面来促进BI成功我的感觉更像是借助BI来提出的管理咨询，而不是信息技术咨询。
>
> 随便谈几句，欢迎指导。
>
> --
> 此事古难全
interstage
互指责,如果技术部门要强势,就会出现一个"牛比无极限"第1类的数据模型包含了第2类业务模型,然后当BI项目失败的时候,就会出现牛比的专家说:我
们的数据模型是先进的,但这个企业业务人员能力还不到等等这类的话,这样的话难道还少吗,这样的故事难道还少吗.
关于我的"非技术层面",不是管理咨询的书,我没这么牛比,提到的概念,在很多管理人员中都知道的,我只是把这些概念做到BI实施中而已,来改变由
于"牛比无极限"第1类的数据模型导致业务部门和技术部门相互指责是现象, 是BI实施的咨询.
关于BI和DW,还是没有达到共识,我在"非技术层面"已经提到了BI,就是一系列的方法和概念,在技术上是DW技术,OLAP技术和数据挖掘技术的综
合运用而已.
On Jun 21, 2:10 pm, "Jerome Qi" <ston...@gmail.com> wrote:
> 最近工作比较忙，一直在TTNN潜水，看到大家在讨论业务建模和数据建模，我也一直做这个方向，很感兴趣。
> 我把业务建模和数据建模的关系理一下，这样争论也有个基础。当然其中肯定也有不当之处，请多多指点。
>
> 先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角 等信息用计算机的语言表示出来。
> 这两类建模从方法到目的都是不同的。
> 第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比重等等内容，这些是业务人员需要完成的工作，有大量的领域 知识在里面。这部分建模的结果有些会反映到信息系统中，有些就只是咨询，反映到用户的日常工作中。
> 第二类，是对企业业务状况的描述，如贷款和抵押品之间是什么关系，与抵押品相关的信息都有那些、产品内部的层级关系，用户分析问题的业务视角等等，这些内容需要 业务人员和信息人员共同参与完成，最终体现在信息系统之中也就是开发人员使用的数据表。
>
> 对于KPI的建模是属于第一类业务建模，它的重点在于哪些因素会影响KPI，影响的比重有多大。但是计算KPI需要的因素以及对这些因素的数据需求都属于第二类 业务建模。
>
> 再说数据建模，数据建模也分为两个步骤，第一类是逻辑模型，第二类是物理模型。
> 这两类模型的差别并不是很大。
> 第一类，逻辑模型，也称为实体关系模型（维度建模可以认为是实体关系建模中的一种），是用计算机术语表示出来的业务状况以及业务分析视角。事实上，逻辑模型就是 前面提到的第二类业务模型。我们是做信息系统的，所作的东西最终都是要体现在计算机里，所以，第二类业务模型和数据模型之间的距离并不大。
> 第二类，物理模型，是将逻辑模型转化成的物理表，这里会出于性能、效率和易用性等考虑对逻辑模型做一些处理。这些处理在逻辑模型中也存在。将逻辑模型转化为物理 模型需要DBA的参与。
>
> 而我们在日常工作中提到的业务建模一般是指第一类业务建模，即从业务的角度来设计KPI等内容。
> 我们在日常工作中提到的数据建模一般是指第二类业务建模，也是第一类数据建模。这两类原本就是同一份工作。也许有很牛的公司会将这两部分分开，请完全不懂技术的 业务专家来设计这部分。但大部分情况下这部分是需要业务和技术都懂的人来完成。我理解innovate511提到的数据建模应该是这类和业务也直接相关的建模， 而不是纯数据的建模。（请innovate511确认。）
>
> 我们再看DW和BI，一般DW里不会有第一类业务模型，但是一定会有第一类业务模型需要的数据，也可能有第一类业务模型分析的结果。而BI里可能有第一类业务模 型，也可能没有第一类业务模型，例如对数据进行OLAP分析就不一定有第一类业务模型。但是勿庸置疑的是，无论是DW还是BI，它的目的都是为业务服务的。所以 说业务驱动BI、DW或者说需求驱动BI、DW都是一定的。但是归根到底，DW和BI都是用来辅助分析的，真正提高企业效益的是使用DW和BI的分析人员。从非 技术层面来促进BI成功我的感觉更像是借助BI来提出的管理咨询，而不是信息技术咨询。
>
> 随便谈几句，欢迎指导。
>
> --
> 此事古难全
interstage
的.你这样才是BI的空对空. BI需要一系列的方法和概念来支撑决策,当然也包含业务模型和数据模型.但唯一不变的就是决策需要分析,分析需要思
考,BI只是给出了思考的一些素材而已,别以为一个牛比的模型就代替支撑决策的一切. BI这个浑水有多深,我搞了10年都不敢说有多了解,你一个模型
就知道这水多深了.太牛比无极限了吧.
> > 此事古难全- Hide quoted text -
>
> - Show quoted text -
Jerome
的综合运用而已.
DW和BI的范围如何划分确实没有定论。您的这种理解方式肯定是正确的。
另一种理解方式是DW主要负责收集和保存数据，BI主要负责分析，这样理解也没有错误。
我个人对这两种理解方式没有偏向，大家都能理解表达的意思就好。
interstage
共识,那就不用讨论了. 只要讨论模型即可,按照raullew的说法"我把511的数据建模看作业务建模，落实到数据库就是物理建模。" 也就是BI
无模型,DW上即是业务模型又是数据模型,真正的"大牛比模型",解决所有BI的问题,是不是这个意思?
raullew
BI可以不要DW，于是乙方的数据集成可以不做了
BI是甲方业务人员的全民BI，于是乙方或者IT部门的报表也可以不做了
那么大家都不用做了，只要按照你的思路，心怀一颗"人人分析，丰衣足食"的心，并随时拿起EXCEL，这个企业或部门的BI，就自然而然的水到渠成了
> > - Show quoted text -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
raullew
business model
这样区分也许不会再有文字上的歧异了
> > 我个人对这两种理解方式没有偏向，大家都能理解表达的意思就好。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
interstage
1, 甲方业务人员按照业务分析角度做报表;2,乙方或者IT部门的报表负责数据质量,来支持甲方业务人员的分析.这2者缺一不可. 你的意思就是乙方
或者IT部门专门做报表,天天做报表就是最牛比的BI了.
> > - 显示引用的文字 -- Hide quoted text -
interstage
又叫什么). OK,我也认可了你这样把business model和data model是一回事,都归于IT了,也就是说BI的成功基础是
IT,IT驱动BI,对吗?
raullew
他们想要业务数据，但不会自己动手的
在这里吹什么什么管理模式没用，你去说服这些人吧
raullew
最后一句话说的什么p话，是那美克星人的推理方法么？
> > - Show quoted text -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
interstage
女人一样的思维方式---想当然的思维方式,这样的思维方式和逻辑,我的确吃不消.
interstage
析和即席查询;3,数据挖掘,4,专题应用,5,KPI/BSC. 应用层次越底,BI越容易实现. 你所负责的甲方就是那些拿日常统计的人,不是需要
分析的人.
所以,我的前提是需要"持续改善"的企业,不是那些垄断性,拿着高工资,不做任何分析,就伸手要统计的甲方,这样的甲方我说服不了.
raullew
第二帖里我说--"和你的看法差不多"
第三帖里你说--"如果你这样理解业务模型和数据模型,我觉得也可以"
不知道是谁吃不消谁
raullew
国内没这么高层次的客户，即便有，高层次的东西还是会自己做的，留给你的只是体力活--实现一下这样的系统功能
Qing
raullew
interstage
界定的问题上展开了.
Raullew认为这就是"511的数据建模看作业务建模，落实到数据库就是物理建模",把它归于技术了,所以就展开了.
其实,这是"持续改善"的继续讨论,业务和技术专家主导业务模型(或者第1类数据模型)如何界定? 就是我提出的对于分析角度业务部门和技术部门各自表
述的"管理视点".
其实解决第2点,也就解决了我们所有以前的讨论,我为什么一开始提"OLAP工具毁了BI",就是因为目前OLAP工具太关注图形形式和报表功能了,所
以我提出OLAP工具应该在第2点上细化实现界定,不然会毁了BI的,我和511的业务模型和数据模型之争论其实也是在争论这个界定,应该是技术还是业
务来主导的问题.jerome把业务模型和数据模型做这个区分,也是在谈这个问题,只是他提出了区分,没说第2点如何界定.
对于界定问题的讨论,有很多.,比如,这段时间大家关注比较多的"股指期货"的历史,产生的时候也是有争论,是股票交易所来管理,还是期货交易所来管
理?争论了7年,才出来结果. 所以我觉得在BI这点上的讨论是正常的.
innovate511
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
interstage
型".我说raullew有点女人思维(呵呵,绝对不是骂他),是因为我觉得他的逻辑有点想当然的意思,就象MM不讲理,我怕了,只好投降了.
raullew
又没有辱及家人，我觉得没什么的
raullew
> > - Show quoted text -- Hide quoted text -
interstage
了. 你说我是"人渣",那真的有点骂和人身攻击的感觉.
hunter
有点不解，为何kpi/bsc是最复杂的应用，能否解释一下呢？我理解kpi就是找出关键指标，搞一个仪表盘，（外加专家库系统？），是否说设定企业的
指标是一个很复杂的管理过程呢？
interstage
KPI/BSC使相关KPI做互动. 现在最大的BI失败就是,下面业务人员用日常统计应用(不思考,不分析),上面领导搞一个仪表盘,号称KPI,离
BSC还差一点,然后说他能分析,高层领导离营运最远,他拿个仪表盘能分析个屁.
我在1讲中提到,其实高层领导唯一能分析的是什么,不是分析运营的成本(这是业务部和市场部分析后,你决策就是了),也不是分析理财的成本(这是财务部
门给出财务杠杆倍数,你决策就是了),高层领导需要分析的是投资的成本(这是你需要想股东汇报的东西,你最大的分析就是这个).所以KPI/BSC不是
高层特有的东西,而现在BI最大的问题就是搞仪表盘让领导看看.这就是领导分析的垃圾,没用.
所以,到KPI/BSC一定是有下面的应用了,不然就会边摆设.
hunter
确实如此，不知能否阐述一下bsc?否则我只能顾名思义，用来给客户/员工打分的东西吗？多谢
Steven
interstage
分. 所以分析中企业KPI的指标全面变绿是不可能,过分追求某一个KPI变绿也不合适.
On Jun 28, 9:22 am, "Steven" <tanhm1...@gmail.com> wrote:
> BSC平衡计分卡的英文缩写，从财务、客户、内部流程及学习与发展四个方面衡量组织战略和组织绩效之间关系的一种绩效管理办法，主要还是体现一个不断改善的过程
>
> Steven
>
> 2007-06-28
>
> > - 显示引用的文字 -- Hide quoted text -