資料科學這一名詞流行了這麼長時間，對於很多企業來說仍然是熟悉而又陌生的詞彙。
對於積極向佈局資料科學應用的企業來說，如何避免走彎路。
Blue Yonder，一個成立於2008年的大資料分析平臺，用他8年的資料科學經驗告訴你，什麼是真正的資料科學、有哪些彎路可以不走。
正如Blue Yonder創始人在採訪中說到：“在這八年裡，我們經歷了不少痛苦的教訓，尤其是在資料科學應用方面。”
以下是採訪原文，請欣賞！
資料科學
我相信許多人都知道什麼是資料科學，但我想分享一下我個人對它的理解：
資料科學的目的是構建自動化的資料驅動運營決策支援系統。
根據這麼嚴格的定義（你也許會有異議），資料科學的唯一目便成了決策的支援和自動化。那麼“運營決策”是什麼？
它是指企業需要頻繁定期進行的大量決策，這些決策對業務KPI（關鍵績效指標）有直接影響，其結果也需要在短時間內進行評估。
企業可能需要作出以下決策，例如：各種產品明天的最佳定價是多少或傳送給供應商X的下一個訂單中各產品的最佳定價是多少。
由於人們經常在不經意間受到影響，因此在大多數情況下，自動決策勝於人類的運營決策，並且自動決策可以顯著提高業務流程的效率。
人類決策偏見列表：
所有這一切實際上意味著，資料科學對於運營決策的意義就像工業機器人對於製造業那樣。正如機器人可以自動執行重複的生產任務一樣，資料科學也可以自動執行重複的運營決策。
DevOps與資料科學
DevOps工作流程旨在克服傳統IT組織中由於開發團隊和運營團隊相互獨立而導致的普遍衝突問題。開發團隊希望開發新功能並希望新功能儘早上線，而運營團隊負責系統的穩定性，因為所有變更都會帶來風險。他們需要儘可能地阻止新功能上線。
在這場衝突中，兩個團隊都忽略了以穩定可靠的新功能為客戶創造價值這一共同目標。
開發人員和運營團隊之間的衝突只是組織結構不合理導致的其中一種情形，對於按功能劃分的其他組織機構也存在相同的問題。
在許多公司裡，資料科學也被困在類似的“功能團隊孤島”中。更詳細的解釋，我建議閱讀這篇《什麼是DevOps》
相關連結：https://theagileadmin.com/what-is-devops/
資料科學-麻煩製造者
有個虛構的段子，但卻透著真實的無奈。兩位管理人員在一次會議上相遇，其中一位經理問道，“你們公司是不是已經開始使用資料科學決策分析了？”另一位回答說：“我們的資料科學家團隊已經成立一年了，但什麼時候可以開始分析還遙遙無期呢。”
為了更好地理解為什麼許多資料科學工作的進展緩慢，我們需要看一下用資料科學進行自動化業務決策的典型工作流程。
下面的工作流程示例是以零售行業為例，同樣也適用於其他行業。
1. 從各種來源提取各種必要的資料：
內部資料來源，如ERP，CRM和POS系統，或來自線上商店的資料。
外部資料，如天氣或公眾假期資料
2. 提取，轉換和載入資料：
關聯資料源
聚合並轉換資料，
用“一張大表”關聯所有資料
3. 機器學習和決策制定：
使用歷史資料來訓練機器學習模型
4. 對於決策，使用當前的最新資料
由此產生的決策被送回ERP系統或其他資料倉儲
這些步驟基本上涉及業務的方方面面，並且需要深入整合到業務流程中，以建立有效的決策系統。
然而這也是迄今為止資料科學決策分析工作最大的麻煩。為了整合資料科學，就需要改變核心業務流程，而改變核心業務流程卻是一項艱鉅的任務。
資料科學本質上是貪婪的
沒有資料科學家會說“目前的資料庫規模足夠明年用的了。”
人們通常覺得資料科學家都是貪婪的，因為他們似乎對可用資源有著不切實際的想法。但實際上，資料科學本身才是貪婪的。
總的來說，以下因素會使資料科學專案的結果更準確：
更多屬性（“列”）
更多歷史資料（“行”）
更獨立的資料來源（例如，天氣，金融市場，社交媒體......）
更復雜的演算法（例如，深度學習）
綜上，這不是資料科學家的問題！原則上，他們有權提出這些要求。幸運的是，我們有方法來解決資源短缺問題，我將在稍後進行論證。
另一個問題是低估了決策的絕對數量。比如一家擁有100個店鋪和5,000種產品的小型超市連鎖店的每日補貨量預測，補貨演算法需要14天的日預測資料才能進行分析。那實際意味著每天需要計算，處理和儲存7百萬個預測資料。
由於建立一個有效的機器學習模型需要許多不同的資料來源，部門之間可能會引入新的共通性和糾結。整個公司必須在公共識別符號（common identifiers）和資料型別（data types）上達成一致。
以前，斷開連結的子部分需要與它們的資料流保持同步。比如，一個自動的日常補貨系統可能要依賴營銷部門的促銷資料和商店的庫存資料。所有必要的資料需要在一天中的固定時間獲取，這樣才方便系統設計決策並及時傳送給供應商。
資料科學家 VS 公司的其他人
現在回到DevOps上來，這一運動旨在克服開發人員和運營團隊之間潛在的偏差。
如果你試圖在一個單獨的地方與資料科學家團隊一起構建自動化決策系統，那麼就會不可避免地出現以上這種問題。
由於資料科學與其他部分的不可分離和對資料的貪婪，其團隊很難成功地將一個系統與其他具有不同績效體制的團隊進行合作。
為了防止或解決這些問題，我們必須接受DevOps模式的基本原則：
調整所有團隊的目標，使他們在工作上不至於產生“衝突”，而是努力實現共同目標。
拆除部門之間的牆，建立跨職能團隊
根據使用者附加值的估量，改進決策方式並分配資源和功能
關於承諾
決策是任何公司成功的核心。因此，在引入資料科學時，整個公司，包括所有的領導層和部門，都需要接受並重視。
運用資料科學進行自動化決策是價值流的重要組成部分。這很可能意味著，你需要改變既定的流程，重組團隊，重新考慮公司的組織架構。
此外，想要成功執行這些措施，你需要獲得必要的認可。每個人都需要知道為什麼會有這些改變，並且還要支援這些決策。如果沒有這種誠摯的諾言，自動化決策就不可能會成功執行。
相關連結：https://www.datascience.com/blog/stakeholder-buy-in-for-data-science-product
反過來，你的資料科學工作必須著重於真正的附加值：一個是需要評估執行成本，包括技術債務成本、複雜性的累積、糾結的增加等；另一方面也要將其與改進後的預期收益進行比較。
資料科學從來不是一個以自我為目標的團隊。
相關連結：https://www.datascience.com/blog/agile-data-science）
拆除資料科學的自我壁壘
DevOps的一個關鍵目標就是使團隊團結以實現公司的共同目標，並且也要拆毀不同團隊之間的壁壘。因為，如果把資料科學家分到一個單獨的小組，安排在一個單獨的房間裡，這將會是一條通往失敗的必經之路。
相關連結：https://www.datascience.com/blog/centralized-data-science
相反，如果我們將資料科學家安排到一個跨職能的團隊中，這將有助於構建一個端到端的完整決策系統，並有助於使其工作與公司目標保持一致。一旦每個部門都連線起來，資料科學家的工作就不會與其他部門相矛盾。
相反，這種決策系統的成功將變成公司的共同利益。以共同努力為特點的整體優化就能夠實現一個共同目標，這將會取代以自我為中心和不一致的目標為特徵的區域性優化。
這個跨職能團隊和其他的團隊一樣致力於相同的質量標準，在質量、彈性或穩健性方面沒有任何妥協的餘地。
相反，由於自動化決策具有較高的風險，我們需要採用更高的標準。同時，遵循“精益思想”的方法，創造一個既便宜又安全的實驗環境。
用奧卡姆剃刀與貪婪作鬥爭
有一個解決問題的原則叫做奧卡姆剃刀（Occam’s razor），也就是：“在相互競爭的假說中，應該選擇假設最少的。”在資料科學領域，我們可以將這個原則重新表述為：
如果兩個資料科學模型的結果是相容的，那麼就採用資源覆蓋面較小的模型。
這條簡單的規則為我們提供瞭如何建立資料科學模型的明確指導，解決了資料科學固有的貪婪性問題。
如果不測量生成值並在整個實現週期中應用此原則，您可能會面臨成本激增，回報有限的問題。
相關連結：https://www.datascience.com/blog/lessons-from-a-canceled-data-science-project
所以，必須要確保資料科學家致力於這一重要原則，因為與資料科學家對抗是非常困難的。他們有資料和專業知識來提出難以提出異議的論點。
創造一種儘可能簡單的，但又失必要的複雜的效率文化。
這同樣適用於不同資料來源的使用。在資料安全領域，有一個“需要知道”（need to know）的原則，即只有需要訪問的人才能訪問資料。
也就是在資料科學的應用中，我們需要衡量所額外新增的資料來源的價值，如果改進不夠顯著，無法證明額外資料的相關性，那麼就要嚴格清除這些資料來源。
結語
資料科學也就是用來支援和自動化決策的。對大多數公司來說，這變得比以往任何時候都重要。由於它是一個決策系統，所以必須成為業務流程的核心。這一事實帶來了一系列嚴重的問題，特別是文化性質的問題，可能是災難性的。
沒有誠意的嘗試往往會導致時間和金錢的浪費，同時還加重了資料科學作為麻煩製造者的聲譽。
將資料科學進行合理的整合是一個不可忽視的轉折點。用DevOps模式來接受資料科學，測量重要的KPIs，從實驗中學習，並不斷改進流程。這是一條真正成為資料驅動公司的道路。
作者Twitter： https://twitter.com/sebineubauer
相關報導：https://www.datascience.com/blog/why-is-it-so-hard-to-put-data-science-in-production