數據科學這一名詞流行了這么長時間，對于很多企業來說仍然是熟悉而又陌生的詞匯。

對于積極向布局數據科學應用的企業來說，如何避免走彎路。

Blue Yonder，一個成立于2008年的大數據分析平臺，用他8年的數據科學經驗告訴你，什么是真正的數據科學、有哪些彎路可以不走。

正如Blue Yonder創始人在采訪中說到：“在這八年里，我們經歷了不少痛苦的教訓，尤其是在數據科學應用方面。”

以下是采訪原文，請欣賞!

數據科學

我相信許多人都知道什么是數據科學，但我想分享一下我個人對它的理解：

數據科學的目的是構建自動化的數據驅動運營決策支持系統。

根據這么嚴格的定義(你也許會有異議)，數據科學的唯一目便成了決策的支持和自動化。那么“運營決策”是什么?

它是指企業需要頻繁定期進行的大量決策，這些決策對業務KPI(關鍵績效指標)有直接影響，其結果也需要在短時間內進行評估。

企業可能需要作出以下決策，例如：各種產品明天的最佳定價是多少或發送給供應商X的下一個訂單中各產品的最佳定價是多少。

由于人們經常在不經意間受到影響，因此在大多數情況下，自動決策勝于人類的運營決策，并且自動決策可以顯著提高業務流程的效率。

人類決策偏見列表：

所有這一切實際上意味著，數據科學對于運營決策的意義就像工業機器人對于制造業那樣。正如機器人可以自動執行重復的生產任務一樣，數據科學也可以自動執行重復的運營決策。

DevOps與數據科學

DevOps工作流程旨在克服傳統IT組織中由于開發團隊和運營團隊相互獨立而導致的普遍沖突問題。開發團隊希望開發新功能并希望新功能盡早上線，而運營團隊負責系統的穩定性，因為所有變更都會帶來風險。他們需要盡可能地阻止新功能上線。

在這場沖突中，兩個團隊都忽略了以穩定可靠的新功能為客戶創造價值這一共同目標。

開發人員和運營團隊之間的沖突只是組織結構不合理導致的其中一種情形，對于按功能劃分的其他組織機構也存在相同的問題。

在許多公司里，數據科學也被困在類似的“功能團隊孤島”中。更詳細的解釋，我建議閱讀這篇《什么是DevOps》

數據科學-麻煩制造者

有個虛構的段子，但卻透著真實的無奈。兩位管理人員在一次會議上相遇，其中一位經理問道，“你們公司是不是已經開始使用數據科學決策分析了?”另一位回答說：“我們的數據科學家團隊已經成立一年了，但什么時候可以開始分析還遙遙無期呢?！?

為了更好地理解為什么許多數據科學工作的進展緩慢，我們需要看一下用數據科學進行自動化業務決策的典型工作流程。

下面的工作流程示例是以零售行業為例，同樣也適用于其他行業。

1. 從各種來源提取各種必要的數據：

內部數據源，如ERP，CRM和POS系統，或來自在線商店的數據。

外部數據，如天氣或公眾假期數據

2. 提取，轉換和加載數據：

關聯數據源

聚合并轉換數據，

用“一張大表”關聯所有數據

3. 機器學習和決策制定：

使用歷史數據來訓練機器學習模型

4. 對于決策，使用當前的最新數據

由此產生的決策被送回ERP系統或其他數據倉庫

這些步驟基本上涉及業務的方方面面，并且需要深入集成到業務流程中，以創建有效的決策系統。

然而這也是迄今為止數據科學決策分析工作最大的麻煩。為了整合數據科學，就需要改變核心業務流程，而改變核心業務流程卻是一項艱巨的任務。

數據科學本質上是貪婪的

沒有數據科學家會說“目前的數據庫規模足夠明年用的了?！?

人們通常覺得數據科學家都是貪婪的，因為他們似乎對可用資源有著不切實際的想法。但實際上，數據科學本身才是貪婪的。

總的來說，以下因素會使數據科學項目的結果更準確：

更多屬性(“列”)

更多歷史數據(“行”)

更獨立的數據源(例如，天氣，金融市場，社交媒體......)

更復雜的算法(例如，深度學習)

綜上，這不是數據科學家的問題!原則上，他們有權提出這些要求。幸運的是，我們有方法來解決資源短缺問題，我將在稍后進行論證。

另一個問題是低估了決策的絕對數量。比如一家擁有100個店鋪和5,000種產品的小型超市連鎖店的每日補貨量預測，補貨算法需要14天的日預測數據才能進行分析。那實際意味著每天需要計算，處理和存儲7百萬個預測數據。

由于建立一個有效的機器學習模型需要許多不同的數據源，部門之間可能會引入新的共通性和糾結。整個公司必須在公共標識符(common identifiers)和數據類型(data types)上達成一致。

以前，斷開鏈接的子部分需要與它們的數據流保持同步。比如，一個自動的日常補貨系統可能要依賴營銷部門的促銷數據和商店的庫存數據。所有必要的數據需要在一天中的固定時間獲取，這樣才方便系統設計決策并及時發送給供應商。

數據科學家 VS 公司的其他人

現在回到DevOps上來，這一運動旨在克服開發人員和運營團隊之間潛在的偏差。

如果你試圖在一個單獨的地方與數據科學家團隊一起構建自動化決策系統，那么就會不可避免地出現以上這種問題。

由于數據科學與其他部分的不可分離和對數據的貪婪，其團隊很難成功地將一個系統與其他具有不同績效體制的團隊進行合作。

為了防止或解決這些問題，我們必須接受DevOps模式的基本原則：

調整所有團隊的目標，使他們在工作上不至于產生“沖突”，而是努力實現共同目標。

拆除部門之間的墻，建立跨職能團隊

根據用戶附加值的估量，改進決策方式并分配資源和功能

關于承諾

決策是任何公司成功的核心。因此，在引入數據科學時，整個公司，包括所有的領導層和部門，都需要接受并重視。

運用數據科學進行自動化決策是價值流的重要組成部分。這很可能意味著，你需要改變既定的流程，重組團隊，重新考慮公司的組織架構。

此外，想要成功執行這些措施，你需要獲得必要的認可。每個人都需要知道為什么會有這些改變，并且還要支持這些決策。如果沒有這種誠摯的諾言，自動化決策就不可能會成功執行。

反過來，你的數據科學工作必須著重于真正的附加值：一個是需要評估執行成本，包括技術債務成本、復雜性的累積、糾結的增加等;另一方面也要將其與改進后的預期收益進行比較。

數據科學從來不是一個以自我為目標的團隊。

拆除數據科學的自我壁壘

DevOps的一個關鍵目標就是使團隊團結以實現公司的共同目標，并且也要拆毀不同團隊之間的壁壘。因為，如果把數據科學家分到一個單獨的小組，安排在一個單獨的房間里，這將會是一條通往失敗的必經之路。

相反，如果我們將數據科學家安排到一個跨職能的團隊中，這將有助于構建一個端到端的完整決策系統，并有助于使其工作與公司目標保持一致。一旦每個部門都連接起來，數據科學家的工作就不會與其他部門相矛盾。

相反，這種決策系統的成功將變成公司的共同利益。以共同努力為特點的整體優化就能夠實現一個共同目標，這將會取代以自我為中心和不一致的目標為特征的局部優化。

這個跨職能團隊和其他的團隊一樣致力于相同的質量標準，在質量、彈性或穩健性方面沒有任何妥協的余地。

相反，由于自動化決策具有較高的風險，我們需要采用更高的標準。同時，遵循“精益思想”的方法，創造一個既便宜又安全的實驗環境。

用奧卡姆剃刀與貪婪作斗爭

有一個解決問題的原則叫做奧卡姆剃刀(Occam’s razor)，也就是：“在相互競爭的假說中，應該選擇假設最少的?！痹跀祿茖W領域，我們可以將這個原則重新表述為：

如果兩個數據科學模型的結果是兼容的，那么就采用資源覆蓋面較小的模型。

這條簡單的規則為我們提供了如何建立數據科學模型的明確指導，解決了數據科學固有的貪婪性問題。

如果不測量生成值并在整個實現周期中應用此原則，您可能會面臨成本激增，回報有限的問題。

所以，必須要確保數據科學家致力于這一重要原則，因為與數據科學家對抗是非常困難的。他們有數據和專業知識來提出難以提出異議的論點。

創造一種盡可能簡單的，但又失必要的復雜的效率文化。

這同樣適用于不同數據源的使用。在數據安全領域，有一個“需要知道”(need to know)的原則，即只有需要訪問的人才能訪問數據。

也就是在數據科學的應用中，我們需要衡量所額外添加的數據源的價值，如果改進不夠顯著，無法證明額外數據的相關性，那么就要嚴格清除這些數據源。

結語

數據科學也就是用來支持和自動化決策的。對大多數公司來說，這變得比以往任何時候都重要。由于它是一個決策系統，所以必須成為業務流程的核心。這一事實帶來了一系列嚴重的問題，特別是文化性質的問題，可能是災難性的。

沒有誠意的嘗試往往會導致時間和金錢的浪費，同時還加重了數據科學作為麻煩制造者的聲譽。

將數據科學進行合理的整合是一個不可忽視的轉折點。用DevOps模式來接受數據科學，測量重要的KPIs，從實驗中學習，并不斷改進流程。這是一條真正成為數據驅動公司的道路。