對于大多數(shù)DT從業(yè)者來講，我們?nèi)粘Ｗ龅拇蠖鄶?shù)工作都屬于支撐類型，無論是報表、取數(shù)、營銷等等，業(yè)務人員提一個需求，我們做一個。在進入大數(shù)據(jù)時代以后，技術上也許我們實現(xiàn)了突飛猛進，但生產(chǎn)關系其實并沒有發(fā)生太大變化，你依舊是那個支撐者的角色。

互聯(lián)網(wǎng)公司在大數(shù)據(jù)技術上對于傳統(tǒng)企業(yè)的影響很大，但我們也許忽略了更為重要的東西，這個東西是什么呢？

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

不到百分之一吧。

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

沒有任何評估的對外盲目推送數(shù)據(jù)，是數(shù)據(jù)比較原始的價值創(chuàng)造方式。

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

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

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

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

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

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

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

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

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

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

很簡單的道理。

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

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

第一層，你只對外推送數(shù)據(jù)

大多數(shù)的取數(shù)、報表、數(shù)據(jù)接口都是這種類型。

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

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

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

90%的數(shù)據(jù)從業(yè)者處于這個階段。

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

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

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

但即使這樣做也已經(jīng)超越了大多數(shù)的數(shù)據(jù)從業(yè)者，雖然還是處于數(shù)據(jù)運營的低級階段。

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

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

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

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

業(yè)務部門知道你能做一些高端的東西，但也僅此而已，沒奢望你能基于數(shù)據(jù)創(chuàng)造什么規(guī)模化的價值。

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

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

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

比如互聯(lián)網(wǎng)的SDK采集數(shù)據(jù)可是直接侵入業(yè)務系統(tǒng)的，這是企業(yè)極度重視數(shù)據(jù)的體現(xiàn)，但有哪個傳統(tǒng)企業(yè)的數(shù)據(jù)部門有這么大的權利？

數(shù)據(jù)中臺和業(yè)務中臺的關系，大家都說是雙向的，但現(xiàn)實中很多時候是單向的，這在傳統(tǒng)企業(yè)尤為明顯。從這個角度講，互聯(lián)網(wǎng)公司的在線基因?qū)嵲谑翘昧耍湔J為理所當然的東西，在你那里可能寸步難行。

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

1、制定模型數(shù)據(jù)開放標準

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

2、效果數(shù)據(jù)自動化采集

根據(jù)接口規(guī)范，數(shù)據(jù)使用方定期生成效果反饋數(shù)據(jù)，并通過自動化采集的模式實現(xiàn)渠道效果數(shù)據(jù)的匯聚，為數(shù)據(jù)運營與迭代優(yōu)化提供基礎。

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

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

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

現(xiàn)在企業(yè)數(shù)據(jù)中臺建設的如火如荼，數(shù)據(jù)中臺的核心是業(yè)務化、服務化、開放化，但我覺得還要加一個，就是閉環(huán)化。

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

第五層，你的數(shù)據(jù)不僅回來了，而且能夠閉環(huán)迭代提升，形成真正的運營生態(tài)

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

OLTP系統(tǒng)現(xiàn)在都在提DevOps，但OLAP其實更需要Ops，我把它叫做MLOps，從數(shù)據(jù)準備、模型迭代、模型發(fā)布、在線預測、到預測結果歸集，每一個環(huán)節(jié)實現(xiàn)在線化、自動化，從而持續(xù)地改進模型的效果和質(zhì)量，否則閉環(huán)迭代提升的生態(tài)是很難實現(xiàn)的。

最后，請問你覺得自己的企業(yè)處在數(shù)據(jù)運營的哪一層？

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

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