對于大多數DT從業者來講，我們日常做的大多數工作都屬于支撐類型，無論是報表、取數、營銷等等，業務人員提一個需求，我們做一個。在進入大數據時代以后，技術上也許我們實現了突飛猛進，但生產關系其實并沒有發生太大變化，你依舊是那個支撐者的角色。

互聯網公司在大數據技術上對于傳統企業的影響很大，但我們也許忽略了更為重要的東西，這個東西是什么呢？

數據建模非常強調快速迭代，而快速迭代的前提是要有好的閉環評估體系，比如AUC就是很好的評估指標，但當我們對外輸送大量數據的同時，到底有多少獲得了哪怕最簡單的反饋和評估。

不到百分之一吧。

從基礎模型、融合模型、挖掘模型再到標簽，當我們盤點所謂的企業數據資產的時候，竟然不知道它們給企業創造了多大的價值，這是很可怕的事情，也許它們現在還配不上稱為是資產。

沒有任何評估的對外盲目推送數據，是數據比較原始的價值創造方式。

業務人員也許滿意我們提供數據的方式，但并不代表就認可其價值，或者根本是無所謂。很多年前負責取數，曾經通過工單系統的分析發現取數結果文件中的15%竟然沒有被打開過，這是誰的問題？

沒有評估，就沒有硬氣的理由。

大數據對外直接變現是很霸氣的，因為賺到的錢的數量就是對于數據價值最好的評估，不需要擺什么事實講什么道理，或者用PPT來裝飾門面，而數據服務企業內部，就完全不是那么回事。

很多人沒有意識到這個問題，反正就是接需求唄；有些人意識到了這個問題，偶偶會抱怨一下，但也僅此而已；個別人看到了業務人員基于自己的取數結果創造的價值，覺得是崗位限制了發揮，因此投奔業務或者另謀高就；僅有極少部分的人會想到如何去改變現狀。

互聯網的大數據技術解決了傳統企業的大數據處理的問題，而互聯網的數據運營那套功夫，既拷貝不了也買不來，甚至看也看不到。比如筆者曾經找某互聯網公司的人想看看他們的數據團隊的組織架構體系，但被以企業秘密為由拒絕了。

回到自己，這些年我們做了很多數據模型，但每一次推廣都顯得有點艱難，迭代的速度太慢了，自己反思來反思去，還是覺得是數據的自動化閉環工作沒有做好，我們跟外部系統并沒有做到暢通的銜接，我們倒在了這關鍵一步。

為什么沒有形成很好的銜接？

當然有各種理由，組織、機制或流程，但更為重要的是，我們有多大的勇氣和技巧去拿回本該拿回的效果數據？

現在各類外圍系統都打著開放數據的名頭來要數據，我們疲于奔命的去實現這些需求，然后把這些數據推送出去，但為什么就沒有及時、硬氣的要求這些外圍系統即刻返回結果呢，如果對面沒有承諾，我們有多大的勇氣去拒絕這些需求？

也許是身處下游身不由己，也許是做事的惰性使然，也許是技術上還有些障礙，更多的是沒有數據運營的思維吧。

很簡單的道理。

從我們手里出去的任何數據，只要無法帶著效果回來，就不能說有多高的數據運營水平，偶偶的亮點、靠人力的大量投入獲得的那點效果不能說明什么。

從這個點出發，我給出了衡量企業數據運營水平高低的5個級別，當然這只是一種看問題的角度。

第一層，你只對外推送數據

大多數的取數、報表、數據接口都是這種類型。

取數創造價值的大多方式，一種是讓領導滿意，一種是讓營銷滿意。但取數卻是最差的數據服務模式。業務人員給你格式要求，然后你把數據取給他，業務人員不會來跟你報喜，說基于你這個數據創造了什么價值，大多數時候你得到的反饋是關于數據本身的質疑。

數據接口是取數的自動化變種，大多也有去無回，很多死掉了你也不知道，只管殺不管埋不僅是數據管理的問題，更是價值創造的問題。

報表滿足了企業的基本生產需求，而你評估這個數據價值的方式，也僅限于看看訪問人數和點擊率，但很難從報表的點擊中分析到什么玄機，因為報表只是數據的呈現，是領導和業務人員做了從信息到知識的轉換動作。

90%的數據從業者處于這個階段。

第二層，你是個有心人，會問問別人家這個數據的用途

報表取數做到一定程度后，你也許已經不滿足于簡單的報表取數，你希望對于業務有更深入的理解，會追根究底的向業務人員了解報表取數的原因，以便為業務人員提供更好的數據解決方案，比如做些分析或者提供些挖掘模型，你甚至能獲得一些效果的反饋。

在周報月報里你開始希望能更多的體現自己報表取數的價值，而不是簡單的數量。以前你只會說完成了多少報表取數需求，現在你會說完成了市場部的XX重點業務數據分析需求，滿足了市場部XX快速營銷的需要，你開始有點運營的思維，但也僅此而已。

但即使這樣做也已經超越了大多數的數據從業者，雖然還是處于數據運營的低級階段。

第三層，你非常有心，開始有主動運營的意識，要求業務人員對于一些場景反饋給你具體效果

報表取數工作已經滿足不了要求，你們開始有專門的組織和人員去從事數據分析和挖掘工作，公司對你的要求變成了服務好精確營銷，精益管理等等，你們開始到一線去尋找需求，然后用項目化的方式去推進模型的建設和運營，希望證明你的數據有用。

為了服務好精確營銷，你們的標簽庫，營銷平臺從0到1也起來了，在你們的工作匯報中，大量的模型開始充斥著PPT版面。

但你的星星之火并沒有怎么燎原，雖然對外提供了大量的數據和模型，偶偶出現點亮點，但你并沒有從提供數據中獲得持續性的反饋，占據大多數的仍然是單向服務的報表和取數，你沒有改變企業數據服務的基本面。

業務部門知道你能做一些高端的東西，但也僅此而已，沒奢望你能基于數據創造什么規模化的價值。

你覺得已經盡力了，開始想著企業的文化、機制和流程是不能改變的，因此很是困惑，能做到這一層已經很不容易。

第四層，你建章立制，要求出去的數據必須回來，否則就不提供數據

很多人把業務數據化簡單的理解為業務系統需要留存原始的數據并推送給大數據平臺，但其實更深層次的含義是業務系統有義務和責任向大數據平臺反饋任何其所需要的數據。

比如互聯網的SDK采集數據可是直接侵入業務系統的，這是企業極度重視數據的體現，但有哪個傳統企業的數據部門有這么大的權利？

數據中臺和業務中臺的關系，大家都說是雙向的，但現實中很多時候是單向的，這在傳統企業尤為明顯。從這個角度講，互聯網公司的在線基因實在是太好了，其認為理所當然的東西，在你那里可能寸步難行。

但我們還是需要嘗試去改變，具體到落地方式，我覺得至少要先要做兩個事情：

1、制定模型數據開放標準

從數據申請、數據使用、到效果反饋，建立一套標準與規范，明確數據開放流程及數據使用方的要求，申請時需登記數據應用場景，必須按照接口規范反饋效果數據等等。

2、效果數據自動化采集

根據接口規范，數據使用方定期生成效果反饋數據，并通過自動化采集的模式實現渠道效果數據的匯聚，為數據運營與迭代優化提供基礎。

現在大家都在提如何推進數據治理，我覺得這是一個好的切入點，考慮到你擁有的提供數據的能力和權利，再考慮到數據閉環道理上的制高點，我們似乎是可以有所期待的。

數據對于業務的賦能，一方面當然要強調全面開放，另一方面則要恪守一些原則，你需要為推送出去的數據價值創造負責，你能負責的唯一辦法是讓對方提供你所需要的評估的東西，沒有底線的開放長遠來講損害企業的利益。

誰知道你推送出去的數據是不是垃圾？業務人員反應過來的時候往往會指責你的模型不給力，也許你還被缺席審判了，但甚至自己還不知道，這是很可笑的事情，數據不要成為了皇帝的新裝。

現在企業數據中臺建設的如火如荼，數據中臺的核心是業務化、服務化、開放化，但我覺得還要加一個，就是閉環化。

數據中臺當然需要開放，但為了數據中臺的可持續發展，就要建章立制確保數據中臺的數據有去有回，否則數據中臺就會走向混亂，在越來越多人的質疑中被打回平臺的原形。

第五層，你的數據不僅回來了，而且能夠閉環迭代提升，形成真正的運營生態

這一層的意思大家都懂的，最近我又創造了一個詞，叫做MLOps。

OLTP系統現在都在提DevOps，但OLAP其實更需要Ops，我把它叫做MLOps，從數據準備、模型迭代、模型發布、在線預測、到預測結果歸集，每一個環節實現在線化、自動化，從而持續地改進模型的效果和質量，否則閉環迭代提升的生態是很難實現的。

最后，請問你覺得自己的企業處在數據運營的哪一層？

如果你問我，大概在3.5，先進的互聯網大多在4以上了吧，其實道理早被別人說完了，但能踐行的又有多少呢？

這篇文章來自于筆者最近關于數據運營的思考，其實跟DevOps有著異曲同工之妙，當你想要規模化、敏捷化的時候，自動化就成為了必需品，現在必須要去干這個事情。