|
網友討論業務建模和數據建模 2007-09-06 14:30:47 最近工作比較忙，一直在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來提出的管理咨詢，而不是信息技術咨詢。 隨便談幾句，歡迎指導。 作者： raullew 20070621 和你的看法差不多，所以我把511的數據建模看作業務建模，落實到數據庫就是物理建模。 全 民BI那等于大家都不要做了，告訴客戶老總說，你們的企業管理方式錯了，要這樣這樣搞，其實這不是搞BI，而是搞管理咨詢了。事實上這種做法在甲方自身沒 有什么執行力，混日子的員工懶得理你，分析人員自有自己的分析方法不干BI的事情，剩下的想要看數據的業務人員肯定是要求助于IT來整理數據，但按道理乙 方又不做實施，于是成了空對空。所以這樣的consultant還是去麥肯錫吧，不要來趟BI這個渾水了。 作者： interstage 20070621 如 果你這樣理解業務模型和數據模型，我覺得也可以。 只不過這樣第2類業務模型和第1類的數據模型就難界定了。 難界定的東西會使業務部門和技術部門相互指責，如果技術部門要強勢，就會出現一個"牛比無極限"第1類的數據模型包含了第2類業務模型，然后當BI項目失 敗的時候，就會出現牛比的專家說：我們的數據模型是先進的，但這個企業業務人員能力還不到等等這類的話，這樣的話難道還少嗎，這樣的故事難道還少嗎。 關于我的"非技術層面"，不是管理咨詢的書，我沒這么牛比，提到的概念，在很多管理人員中都知道的，我只是把這些概念做到BI實施中而已，來改變由于"牛比無極限"第1類的數據模型導致業務部門和技術部門相互指責是現象， 是BI實施的咨詢。 關于BI和DW，還是沒有達到共識，我在"非技術層面"已經提到了BI，就是一系列的方法和概念，在技術上是DW技術，OLAP技術和數據挖掘技術的綜合運用而已。 作者： interstage 20070621 既 然你認為全民BI是大家都不做，你以為每個人做同一件事情呀，以為是大鍋飯。 那你對BI的理解，就是分析一個事情，每個人都是一樣的思路，才是正確的。你這樣才是BI的空對空。 BI需要一系列的方法和概念來支撐決策，當然也包含業務模型和數據模型。但唯一不變的就是決策需要分析，分析需要思考，BI只是給出了思考的一些素材而 已，別以為一個牛比的模型就代替支撐決策的一切。 BI這個渾水有多深，我搞了10年都不敢說有多了解，你一個模型就知道這水多深了。太牛比無極限了吧。 作者： Jerome 20070621 關于BI和DW，還是沒有達到共識，我在"非技術層面"已經提到了BI，就是一系列的方法和概念，在技術上是DW技術，OLAP技術和數據挖掘技術的綜合運用而已。 DW和BI的范圍如何劃分確實沒有定論。您的這種理解方式肯定是正確的。另一種理解方式是DW主要負責收集和保存數據，BI主要負責分析，這樣理解也沒有錯誤。我個人對這兩種理解方式沒有偏向，大家都能理解表達的意思就好。 作者： interstage 20070621 OK， 你這個描述，我也是贊同的，我把你這個定義的BI，稱為狹義的BI，主要是解決前端層面的技術，工具等等的系統都包含在里面。 如果這個定義達到共識，那就不用討論了。 只要討論模型即可，按照raullew的說法"我把511的數據建模看作業務建模，落實到數據庫就是物理建模。" 也就是BI無模型，DW上即是業務模型又是數據模型，真正的"大牛比模型"，解決所有BI的問題，是不是這個意思? 作者： raullew 20070621 從 你的邏輯，我只能認為是大家都不做了BI可以不要DW，于是乙方的數據集成可以不做了BI是甲方業務人員的全民BI，于是乙方或者IT部門的報表也可以不 做了那么大家都不用做了，只要按照你的思路，心懷一顆"人人分析，豐衣足食"的心，并隨時拿起EXCEL，這個企業或部門的BI，就自然而然的水到渠成 了。 我是把business model等同于data model的，但這是IT領域建模的business model，不是商業領域的business model， 這樣區分也許不會再有文字上的歧異了 作者： interstage 20070621 呵 呵，你太幽默了，既然你把business model和data model搞成一樣了，而且不是商業領域的business model(那這個又叫什么)。 OK，我也認可了你這樣把business model和data model是一回事，都歸于IT了，也就是說BI的成功基礎是IT，IT驅動BI，對嗎? 作者： Qing 20070621 謝謝jerome給業務模型和數據模型一個區分，看完之后我的理解是有三種： 一、是業務人員主導的：第一類業務模型 作者： interstage 20070621 呵 呵，jerome說法我同意，Qing你的總結我也贊同，后來的討論就是集中在第2點上，業務和技術專家主導業務模型(或者第1類數據模型)，是如何界定 的問題上展開了。 Raullew認為這就是"511的數據建模看作業務建模，落實到數據庫就是物理建模"，把它歸于技術了，所以就展開了。 其實，這是"持續改善"的繼續討論，業務和技術專家主導業務模型(或者第1類數據模型)如何界定? 就是我提出的對于分析角度業務部門和技術部門各自表述的"管理視點"。 其 實解決第2點，也就解決了我們所有以前的討論，我為什么一開始提"OLAP工具毀了BI"，就是因為目前OLAP工具太關注圖形形式和報表功能了，所以我 提出OLAP工具應該在第2點上細化實現界定，不然會毀了BI的，我和511的業務模型和數據模型之爭論其實也是在爭論這個界定，應該是技術還是業務來主 導的問題。jerome把業務模型和數據模型做這個區分，也是在談這個問題，只是他提出了區分，沒說第2點如何界定。(amt) 對于界定問題的討論，有很多。，比如，這段時間大家關注比較多的"股指期貨"的歷史，產生的時候也是有爭論，是股票交易所來管理，還是期貨交易所來管理?爭論了7年，才出來結果。 所以我覺得在BI這點上的討論是正常的。 |
|
|
來自： 鈴兒響叮當 > 《商務智能與競爭情報》
