近年來，大數據旋風以“迅雷不及掩耳之勢”席卷全球，不僅是信息領域，經濟、政治、社會等諸多領域都“磨刀霍霍”向大數據，準備在其中逐得一席之地。然而，很多公司在邁入大數據領域后遭遇“滑鐵盧”。在此，本文盤點了一系列大數據失敗項目，深究其原因，具有警示意義。

　　八個大數據項目失敗案例

對數據過于相信。2008年，Google第一次開始預測流感就取得了很好的效果，比美國疾病預防控制中心提前兩禮拜預測到了流感的爆發。但是，幾年之后，Google的預測比實際情況(由防控中心根據全美就診數據推算得出)高出了50%。媒體過于渲染了Google的成功，出于好奇目的而搜索相關關鍵詞的人越來越多，從而導致了數據的扭曲。

低估大數據復雜程度：在美國有幾個互聯網金融公司專做中小企業貸款。但是中小企業貸款涉及的數據更復雜，而且中小企業涉及到整個行業非常特殊的一些數據，比如非標準的財務報表和不同行業、不同范式的合同，他們沒有很專業的知識，是很難理解或者很難有時間把它準確挖掘出來。

當時大數據團隊想用一個很完美的模型把所有的問題都解決掉，比如把市場和信貸的解決方案全部用一個模型來解決，但因為數據的復雜程度，最后證明這種方法是失敗的，而且90%的時間都在做數據清理。這就說明，想通過大數據技術一下子解決所有的問題是很難成功的，而是要用抽絲剝繭、循序漸進的方式。

管理層的惰性：某家旅游公司系統通過web日志數據的挖掘來提升客戶洞察。結果證明，用戶在瀏覽網站之后，隨后的消費行為模式與管理層所認為的不一致。當團隊匯報此事時，管理層認為不值一提。但是，該團隊并沒有放棄，并通過嚴密的A/B測試，回擊了管理層的輕視。

這個案例的最終結果，不是每個CIO都能期盼的。但是，有一點是可以確定的：做好和管理層打交道的準備，讓他們充分理解大數據是什么以及相應的價值。

應用場景選擇錯誤。一家保險公司想了解日常習慣和購買生命保險意愿之間的關聯性。由于隨后覺得習慣太過于寬泛，該公司將調查范疇限定到是否吸煙上。但是，工作仍然沒有實質進展。不到半年，他們就終止了整個項目，因為一直未能發現任何有價值的信息。

這個項目的失敗是由于問題的復雜性。在抽煙與否之間，該公司沒有注意到還有大片灰色地帶：很多人是先抽煙而后又戒煙了。在將問題簡單化動機的驅動下，這個部分被忽略了。

問題梳理不夠全面。一家全球性公司的大數據團隊發現了很多深刻的洞察，并且計劃通過云讓全公司共享。結果這個團隊低估了效率方面的損耗，由于網絡擁塞的問題，無法滿足全球各個分支順暢提交數據運行分析的需求。

該公司應該仔細思考下如何支撐大數據項目，梳理所需的技能并協調各IT分支的力量進行支持。由于網絡、安全或基礎設施的問題，已經有太多的大數據項目栽了跟頭。

缺乏大數據分析技能。一家零售公司的首席執行官不認同亞馬遜規模化、扁平化的服務模式，因此讓CIO構建一個客戶推薦引擎。項目最初的規劃是半年為期，但是團隊很快認識到諸如協同過濾(collaborative filtering)之類的概念無法實現。為此，一個團隊成員提出做一個“假的推薦引擎”，把床單作為唯一的推薦產品。這個假引擎的工作邏輯是：買攪拌機的人會買床單，買野營書籍的人會買床單，買書的人會買床單。就是如此，床單是唯一的、默認的推薦品。

盡管可笑，這個主意其實并不壞，默認的推薦也能給企業帶來銷售上的提升。但是，由于大數據相關技能的缺失，真正意義上的引擎未能實現。

提出了錯誤的問題。一家全球領先的汽車制造商決定開展一個情感分析項目，為期6個月，耗資1千萬美元。項目結束之后，該廠商將結果分享給經銷商并試圖改變銷售模式。然后，所得出的結果最終被證明是錯誤的。項目團隊沒有花足夠的時間去了解經銷商所面臨的問題或業務建議，從而導致相關的分析毫無價值。

應用了錯誤的模型。某銀行為判斷電信行業的客戶流失情況，從電信業聘請了一位專家，后者也很快構建了評估用戶是否即將流失的模型。當時已進入評測驗證的最后階段，模型很快就將上線，而銀行也開始準備給那些被認為即將流失的客戶發出信件加以挽留。

但是，為了保險起見，一位內部專家被要求對模型進行評估。這位銀行業專家很快發現了令人驚奇的事情：不錯，那些客戶的確即將流失，但并不是因為對銀行的服務不滿意。他們之所以轉移財產(有時是悄無聲息的)，是因為感情問題——正在為離婚做準備。

可見，了解模型的適用性、數據抽象的級別以及模型中隱含的細微差別，這些都是非常具有挑戰性的。

八種導致失敗的理由

縱觀上述失敗案例，可歸結為以下八種導致大數據項目失敗的常見原因。

管理層阻力。盡管數據當中包含大量重要信息,但Fortune Knowledge公司發現有62%的企業領導者仍然傾向于相信自己的直覺,更有61%的受訪者認為領導者的實際洞察力在決策過程中擁有高于數據分析結論的優先參考價值。

選擇錯誤的使用方法。企業往往會犯下兩種錯誤,要么構建起一套過分激進、自己根本無法駕馭的大數據項目,要么嘗試利用傳統數據技術處理大數據問題。無論是哪種情況,都很有可能導致項目陷入困境。

提出錯誤的問題。數據科學非常復雜,其中包含專業知識門類(需要深入了解銀行、零售或者其它行業的實際業務狀況);數學與統計學經驗以及編程技能等等。很多企業所雇用的數據科學家只了解數學與編程方面的知識,卻欠缺最重要的技能組成部分——對相關行業的了解，因此最好能從企業內部出發尋找數據科學家。

缺乏必要的技能組合。這項理由與“提出錯誤的問題”緊密相關。很多大數據項目之所以陷入困境甚至最終失敗,正是因為不具備必要的相關技能。通常負責此類項目的都是IT技術人員——而他們往往無法向數據提出足以指導決策的正確問題。

與企業戰略存在沖突。要讓大數據項目獲得成功,大家必須擺脫將其作為單一“項目”的思路、真正把它當成企業使用數據的核心方式。問題在于,其它部門的價值或者戰略目標有可能在優先級方面高于大數據,這種沖突往往會令我們有力無處使。

大數據孤島。大數據供應商總愛談論“數據湖”或者“數據中樞”,但事實上很多企業建立起來的只能算是“數據水坑兒”,各個水坑兒之間存在著明顯的邊界——例如市場營銷數據水坑兒與制造數據水坑兒等等。需要強調的是,只有盡量緩和不同部門之間的隔閡并將各方的數據流匯總起來,大數據才能真正發揮自身價值。

在大數據技術之外遇到了其它意外狀況。數據分析僅僅是大數據項目當中的組成部分之一,訪問并處理數據的能力同樣重要。除此之外,常常被忽略的因素還有網絡傳輸能力限制與人員培訓等等。

回避問題。有時候我們可以肯定或者懷疑數據會迫使自身做出一些原本希望盡量避免的運營舉措,例如制藥行業之所以如此排斥情感分析機制、是因為他們不希望將不良副作用報告給美國食品藥品管理局并承擔隨之而來的法律責任。

在這份理由清單中,大家可能已經發現了一個共同的主題:無論我們如何高度關注數據本身,都會有人為因素介入進來。即使我們努力希望獲取對數據的全面控制權,大數據處理流程最終還是由人來打理的,其中包括眾多初始決策——例如選擇哪些數據進行收集與分析、向分析結論提出哪些問題等等。

為防止大數據項目遭遇失敗，引入迭代機制是非常必要的。使用靈活而開放的數據基礎設施,保證其允許企業員工不斷調整實際方案、直到他們的努力獲得理想的回饋，最終以迭代為武器順利邁向大數據有效使用的勝利彼岸。