文|傅一平
《 》裡，筆者簡要的介紹了經營分析1.0起步建設的情況，今天首先講講2004-2006年這3年來，自己和團隊一起成長的故事，然後再談談2006年經營分析1.5的起步。
一、成長的故事
1、實習期間的笨鳥先飛
2004年自己進入公司後，馬上被安排去溫州實習，在去溫州的大巴車上，我接到了一個電話：
“我是nova，歡迎博士加入經營分析組，希望你馬上回來，這邊缺人很厲害啊！”
這是主管給我打的第一個電話，還是很激動的，想著自己啥都不懂，主管就對於我寄予厚望，我一定得好好幹哪。
現在走上管理崗位後，也經常會反思一下，新人是很需要上級鼓勵的，也許你只是客套一下，但對於新人很重要，當然要做到這一點其實也蠻難的，有時候會覺得有些虛偽，情商太低的緣故吧。
自己當時實習的目標是希望回省公司後能立馬上手幹活，三個月的實習期，我每天二點一線，在賓館和實習的溫州公司之間往返穿梭，最有印象的就是每次在路上都會看到周杰倫動感地帶那個廣告牌，還有就是“在我地盤這 你就得聽我的......”。
實習期間看完了公司主要數據庫的PDM，把歷年的取數腳本研究了下，大致看懂了經分報表的代碼，把幾百張報表下載到電腦裡研究，然後對每張報表的每個指標進行了註釋，形成了自己第一本數據字典，同時把集團公司的經營分析的規範翻了幾遍，對於數據倉庫有了基本的瞭解。
我編寫的青澀的數據字典
也許你會說好厲害啊，但其實只要勤奮點的人都能做到，我屬於那種天賦一般，但相信勤能補拙的人，這可能跟大學的經歷有關。
自己從浙江大學高級工程班出來，寫過彙編、C、VC等等，博士期間幹過很多工程項目，比如在2001年就已經開始用BP算法做牌照識別了，當然那個算法是我繼承師兄的。
記得當時在南昌某個收費站待了一個月採集牌照來進行訓練，而且還與師弟合作出過一本《Visual C++精彩實例詳解》的書。但我看到過牛逼的人寫得代碼是什麼水平，自己顯然是達不到那個境界的，有時挺自卑。
能把單位的相關文檔和代碼看一遍僅僅是蠻力而已，至於為什麼會準備的比較充分，也許是因為實習前自己已經在省公司呆了2個禮拜，有意識的把能拷貝的東西都拷貝到了，笨鳥先飛吧。
自己的求知慾還可以，在實習期間曾經大著膽子給集團的經營分析專家寫過郵件，這不還找到了當年的那封郵件，分享給大家。
“您好,我是XX移動的新員工,領導要我做經營分析的項目,現在我在地市實習,估計2個月後就回省公司正式開始工作了,由於以前在學校沒做過類似的項目,因此對這一塊還是很陌生的,我希望在實習期間對經營分析有個比較詳細的瞭解,這樣我上崗後能快速的進入角色。
由於剛進公司,我對移動還不是太瞭解,我也沒有任何接觸使用開發BOSS系統的經驗,我也知道對一個剛從學校出來的新手直接上馬從事移動經營分析是有難度的。我現在希望能快速的融入這個角色,因此希望知道搞經營分析需要掌握的一些東西。
我有的資料是boss系統的比如計費,營業等的數據字典,還有是同事給我的一些關於經營分析的文檔,比如很對規範,概要設計,物理設計等,對於這些文檔我也看了不少，我在學校的時候也參加了很多項目開發,但發現經營分析這個項目太大了,對於其中的技術細節我不可能都能掌握。
比如建設數據倉庫,就要抽取,要用到datastage，前臺展示要用到brio,要了解olap,比如XX移動用DB2,我還要了解DB2等大量的技術,當然對於源數據庫,比如計費等,我還得了解其中的各種字段等的說明和大量的業務規範等,作為移動技術人員,我不知道自己需要掌握這些到什麼程度,需要在跟開發商之間扮演什麼角色，作為一名新人，我需要哪些技術儲備。
偶然間我在dwway論壇和中國計費網看到了您的帖子,欽佩而且振奮,您是集團公司關於BOSS和經營分析系統的策劃者,我想您的建議對我來說是很珍貴的,非常希望能得到您的建議,我也希望能為中國移動貢獻自己的力量。
我主要問題可以歸結為3個:
1、上手經營分析我需要了解哪些技術(比如數據倉庫等)
2、需要了解哪些移動的東西,比如boss系統,牽扯到各種數據庫以及細節
3、對於技術我需要掌握到底什麼程度,我在與開發商協調過程中需要扮演什麼角色,即我的任務是什麼
非常希望能得到您的答覆，謝謝"
一晃15年過去了，現在的我可能變成了以前的他，當然我不是什麼專家，而很多網友就是當年的自己，對於未來充滿憧憬和希望。
這一路走來我犯了很多錯誤，如果能寫出來，可能對大家有益吧，這也是我寫文章和開微信群的一個原因。
當3個月的實習完成後，我對於公司的數據已經有了很多的理解，起跑線其實是不錯的，實習期後的個人成長經歷以後再講。
2、第一代數據開發平臺BOSSREP
雖然我在第一篇文章中誇過PL/SQL Developer這個集成開發工具，但它也是有問題的，因為它只是個方便的取數工具，當取數需求越來越多的時候，你會發現管理的複雜度直線上升。
比如沒有代碼的管理、沒有數據字典的管理、沒有調度的管理，跑10個腳本要開10個窗口，那真叫一個混亂。
這個時候老朱上場了，老朱是對我影響很大的一名合作伙伴的數據專家，在職業生涯的初期幾乎所有的疑難問題都會找他，無論團隊碰到了什麼問題，老朱幾乎都能解答，代碼的問題、數據質量的問題、數據庫方面的問題等等，不一而足，老朱就是萬能的代名詞。
老朱研發了牛逼的第一代BOSSREP這個C/S架構的開發工具，阿里Dataphin等強大的開發工具近幾年才出現，而BOSSREP這個開發工具2005年就出來了，它囊括了當前大多數開發管理工具的基本功能，包括元數據管理（那個時候主要管報表）、代碼管理、調度管理、分佈式管理等等。
牛逼的BOSSREP
我舉2個很好的功能：
分佈式管理其實就是做了一個事，將串行的任務做成並行，比如我們的數據倉庫大多是按照地市分表設計的，以前PL/SQL Developer跑11個地市只能一個個串行跑或者開11個窗口跑，現在配置一下就可以了，效率提升了5倍以上。
代碼管理則是採用拆分的思想，你可以把一段很長的腳本按照業務邏輯拆分成多段，運行的時候可以進行分段控制，調試和運行實在是太方便了。
現在都在提中臺，BOSSREP就是那個時候最牛逼的中臺，自從有了這個工具，我們取數和報表開發的效率直線上升，原來2004年剛進公司的時候一個月也就20-30個取數需求，2006年的時候已經上百了。
下面是一段當年的代碼，你看裡面已經出現了通配符“$AREACODE”了，BOSSREP自動會把它轉化成11個腳本並行跑。
3、第一代寬表ALL_XXX_YYYYMM
雖然我們的數據倉庫項目建設了統一的模型體系，但這套模型體系當初主要是圍繞用戶、業務、競爭幾個主題構建的，基於這些主題出了公司的核心KPI，而KPI在很長的時間內是穩定的，決定了這套模型變化很少。
在日常的公司經營活動中，KPI是服務管理者的，管理者會分解KPI指標到基層，基層除了關注KPI，還要關注如何完成這些KPI，因此由KPI會衍生出大量的執行類指標。
執行類指標對於一線才是有實際指導價值的，比如市場佔有率這個KPI指標，基層一線看光這個指標沒用，還需要分解成一系列可操作的相關指標，比如放號用戶數，而放號的粒度可能還太粗，因此還要分解到營業廳、社會渠道、電渠等等，這樣才能壓實責任，某某社會渠道每天要放號多少才是一線指標的剛需。
市場變化很快，執行類指標變動也會很快，因此日常的運營無法靠這套穩定的倉庫模型體系支撐，當然你可以說去改啊，但改錯了成本就太高了，我們得自己想辦法。
老朱創造了一套貼近一線實際的寬表，我們叫它ALL表，意思是無所不能，後續大多數的取數和報表實際都是依賴ALL表的，我們對外談的是面子，即標準化的倉庫模型，對內實際運營的則是這套ALL表，由於ALL表沒有什麼負擔，因此能夠隨著業務滋養而快速成長。
這就是穩定、責任和快速、創新的矛盾。
數據中臺的共享說說容易，當真的在日常運營中要你去改一箇中臺模型，你還得掂量下改錯的代價，因為風險隨著共享變大了，新建一套倉庫模型誰都會，但要會運營則是另一個境界的事情。
筆者後來在這個基礎上也建立了一套ALL表，命名是ALL_XXX_YYYYMMDD，就是把月表演進為了日表，這是我的私貨。你要提升效率，就得做些創新，讓自己成為一個閒人，才有功夫去想些其他有趣的事情。
現在建表啥的都有規矩，今天你在庫裡建一張不規範的表，明天機器就給你揪出來，因此私活就很難做了，創新的苗子也往往被扼殺了，因此規範化的創新企業往往要在管理方面下大工夫。
二、2006，經營分析1.5的前奏
1、數據集市
BASS1.0的九大主題推出後，應用情況實際並不理想，前文中我也已經提到，自頂向下的業務規範到了本地往往水土不服，而且DB2這類數據倉庫是很難推廣到一線使用的，這就形成了兩張皮的現象，一方面省公司轟轟烈烈的在做建設和推廣，另一方面一線仍然在自己老舊的本地機器上做著自己的報表。
為了解決這個問題，數據集市孕育而生，目標有三個：
- 擴大省級經營分析系統的服務範圍，省級經營分析系統為地市數據集市提供充足的、準確的數據，同時提供全省統一部署的經營分析工具，地市數據集市面向地市應用開展建設，是對省級經營分析系統功能的延伸
- 地市數據集市作為省級經營分析系統的補充，為各地市一線生產營銷人員提供更加靈活，更加及時，更有針對性的分析應用，更好地支持日趨激烈的市場競爭活動
- 地市數據集市作為各地市自主的數據分析和演練平臺，可以充分針對地市個性化的業務需求進行滿足，同時在個性化應用逐漸固化後，將亮點業務應用整合進各省級經營分析系統，實行全省推廣，應驗共享
集團召集了部分省公司實施數據集市的試點，效果還是非常顯著的，數據集市上線後經分的使用點擊率提升200%以上。
這個容易理解，地市不僅有了省公司提供的小型機，安裝了自己喜歡的ORACLE數據庫，還可以利用省公司的工具開發自己的報表，的確能提升生產力。
但這僅僅是試點的結果，實際的挑戰可太大了，後面再講吧。
2、元數據
筆者第一次聽說元數據這個名詞也是在2006年，因為集團在這一年開展了元數據的省公司試點。元數據關於數據的數據這個定義頗令人費解，一定程度上阻礙了其推廣。
元數據本質上就是對數據的描述（也包括上下文），比如數據的所屬區域、取值範圍、數據間的關係、業務規則、數據來源等等，在一座圖書館中，如果認為每一本書的內容都是數據，用來查找每一本書的索引就是元數據。
理解了這個本質，你對元數據可以信手拈來，比如你有一個EXCEL，EXCEL包含數據，那麼這個EXCEL的名字、EXCEL裡的SHEET名字，SHEET裡面任何行列的名字，都是元數據，因為它們都可以幫助你來解釋EXCEL裡面的數據。
元數據的目的跟語言也可以類比，語言讓說話的雙方都能聽得懂是一個意思，而元數據讓使用數據的雙方也能理解為同一個意思，所謂的“書同文，車同軌”。
我翻開了塵封的一份元數據PPT文檔，裡面是這麼描述管理元數據的意義的：
- 理解企業內部的信息資源
- 數據的瀏覽和歸納
- 數據在企業內部橫向與縱向傳遞
- 保持整個企業的標準（保證企業內部統一的商業定義和商業規則）
- 數據生命週期的管理
元數據其實就是數據的知識庫，而知識可以指導行動，以下是元數據的一張功能結構圖，方便你去理解。
而為了在異構環境下，幫助不同的數據倉庫工具、平臺和元數據知識庫進行元數據交換，OMG這個組織又定義了元模型（CWM，Common Warehouse Metamodel），元模型實際上是元數據的一個定義標準，有哪些標準呢，見下圖，有點抓狂沒關係，繼續往下看。
在形成CWM標準以前，數據倉庫要進行集成的情況如下圖所示：
在形成標準以後的情況如下圖所示：
比如描述一張表可以有很多種方式，你既可以用三個元數據來定義，比如表名、表描述、表主鍵，也可以用五個元數據來定義，比如表名、表描述、表主鍵、歸屬數據庫、容量等等，假如你需要在異構數據庫的表之間交換數據，就必須有個元數據標準，大家講的表都是同一個模式，即都是五個元數據來描述，而且這五個元數據含義都一樣，這就是CWM要做的事情。
表的描述是元數據，但要規定怎麼描述一張表，則是元模型做的事情，這是抽象的抽象。
元模型的應用無處不在，比如我們的DACP開發管理平臺，假如要新建一張表，這張表的填充要素有哪些呢？
其實就是由CWM控制的，只是很多企業沒有用CWM那套標準而已，而現在數據倉庫相關的企業往往需要遵循這個標準，否則就很難去做開放。
元數據作為試點是成功的，但真正納入生產那坑就太多了，這個以後再說。
3、數據質量管理
除非一個企業做過很大的努力來提高數據質量，企業的數據錯誤率一般都會近似達到1-5%，這是Redman通過對多家企業的實際評估得出的結論。
我們搞數據的每天都在處理數據質量問題，但要體系化的建設數據質量管理體系則是巨大的挑戰，因為影響數據質量的因素太多了，我給你看一個圖，你就知道了，這張圖還是很牛逼的。
為了保障經營分析系統的可靠和有效，統一考慮整個系統平臺的數據質量問題，集團要求在經營分析系統中通過元數據實現方式，建立數據質量管理平臺，以豐富完善系統各級數據質量的保障機制。下圖是數據質量管理體系結構圖示例，還是很清晰的。
- 數據層定義了系統管理數據的範圍，主要包括經營分析系統不同的子系統，包括經分數據源、ETL系統、經營分析系統、OLAP等應用系統以及前端的應用。
- 存儲層提供了進行數據質量管理的技術手段和數據，主要包括元數據管理、算法庫、規則庫和中間信息。
- 功能層主要包括了元數據的基本支撐功能、質量檢查的基本功能和輔助功能
- 應用層包括了信息地圖、數據質量評估、接口數據異常分析、指標一致性分析、需求變更影響分析等等應用
如果覺得我寫的不錯，歡迎關注並轉發，遇到問題可以在文章下面評論。
閱讀更多 IT技術管理那些事兒 的文章
