數據科學項目的最后一步可以說也是最難的，即將有望實現其目的的原型作為概念驗證（PoC）并最終部署它。部署數據產品意味著通過將數據科學項目的輸出（例如機器學習算法或可視化儀表板）集成到相應的業務流程中，使其可供用戶使用。這說起來容易做起來難。以下是一些技巧，希望可以幫助克服數據產品部署的障礙：

1. 配備數據工程師

數據科學工作被稱為最受歡迎的工作。雖然數據和機器學習工程師對于數據科學項目的成功不可或缺，但他們的作用至少同樣重要。數據科學家通常參與開發和原型設計階段，以探索數據、進行實驗、從中設計特征，最后開發機器學習和統計模型。然而，許多數據科學項目的真正瓶頸是部署——數據和機器學習工程師的工作。

當部署原型（例如機器學習模型）時，“數據科學項目”就變成了“軟件開發”項目。這是兩件截然不同的事情。要了解其中的原因，請考慮新車的開發。在研發階段，對汽車的許多調整都可以手動定制，例如以特定方式塑造車身以確保最佳的空氣動力學特性。目標是測試和創建給定原型的最佳功能。然而，如果這樣的原型車要投入批量生產，目標就會改變為生產盡可能多的廉價且高質量的汽車。為了確保廉價和高質量的生產，原型的某些功能可能必須妥協。這是一個全新的挑戰，與研發階段非常不同。不能將汽車交給生產主管并期望立即生產數千輛。數據科學項目也是如此。

在開發過程中，很多事情（例如糾正數據中的錯誤）可以由數據科學家手動完成。但如果最終的數據產品要投入生產，這本身通常是一個新項目，也是一個全新的挑戰。

數據產品需要經過測試和設計，能夠容錯并滿足性能要求。這需要時間和具有適當技能的工程師，最好具有軟件開發和數據科學/機器學習知識的背景。因此，對于每個數據科學項目，肯定需要一名工程師。我們建議在組建數據科學團隊時，目標應該是擁有更多的工程師和數據科學家。

2. 在業務部門、數據科學部門和IT運營部門的合作三角中運營數據項目

在孤立組織的公司中，數據科學團隊通常很少或根本不與其他部門合作，特別是 IT 和業務部門。在數據科學項目的實施過程中，數據科學/工程-業務部門-IT 三角團隊的合作對于促進最終產品的成功部署至關重要。業務部門，即數據產品的用戶，應該定期溝通他們的需求，而數據科學團隊和IT部門應該評估技術可行性，并嘗試找到解決方案來解決需求和可行性之間的不匹配。這會阻止實施滿足要求但從技術角度來看不可部署的項目，反之亦然。

例如，在生產機器的預測維護用例中，業務部門需要定義他們希望如何使用數據產品。應該提前多長時間預測故障？準確度需要達到多高才能獲得有利的業務案例？這些要求必須由數據科學團隊翻譯并由 IT 部門評估：傳感器數據的粒度是多少——毫秒、秒、分鐘？是預先匯總的嗎？這個頻率是否足夠高，足以提前這么長時間做出預測？實現該用例需要什么計算能力和工具（例如，是否有可以應對計算負載的分布式系統）？部署的目標環境是什么？它是否具有必要的工具？等等。

這些利益相關者的合作確保數據科學用例的設置不會因需求和可行性之間的不匹配而阻礙其部署。

3. 注意技術和組織債務的成本

技術債務的概念在軟件開發中是眾所周知的。它指的是人們選擇一種在短期內易于實施的解決方案，但從長遠來看不是最優的并且會付出代價的解決方案（即“快速而骯臟的解決方案”）。從長遠來看，這些有害影響會隨著債務的增加而增加，例如代碼運行速度可能會變慢，或者維護和改進會更加困難。

數據科學項目也存在這種技術債務。像“現在讓我們對數據轉換進行硬編碼，因為我們明天需要顯示一些結果”之類的情況對于數據科學家來說肯定聽起來很熟悉。他們還將知道，隨著項目的繼續，而不是重構（即清理），從長遠來看，此類技術債務可能會帶來高昂的成本。

就像經濟理論中的“債務”不一定是壞事，但在數據科學項目中需要仔細考慮成本和收益。除了技術之外，還要考慮組織債務：

3.1 什么是技術債務

如上所述，這主要與開發人員和數據科學家相關：在編寫代碼時，總是傾向于尋求快速而骯臟的解決方案，特別是考慮到時間壓力。但在部署數據科學項目時，此類解決方案會適得其反，因為它們可能會妨礙代碼的可讀性、可維護性和性能。數據環境中的技術債務示例包括：

●使用在開發中使用方便但性能不佳或難以部署的工具（例如，R 用于性能敏感的應用程序）

●硬編碼和手動計算，而不是編寫專為穩定性而設計的代碼并針對極端情況進行測試（即開發測試）

●沒有在代碼文檔上花費足夠的時間

這些問題在軟件工程學科中是眾所周知的。然而，由于許多數據科學家來自計算機科學以外的背景，其中一些數據科學家不得不再次經歷艱難的過程。

3.2 什么是組織債務

技術債務的基本機制適用于我們的組織層面，尤其與管理者和決策者相關。示例包括：

●創新實驗室和核心 IT 之間不兼容的技術工具堆棧是決策者承擔了將實驗室建設為脫離企業 IT 游輪的“快艇”的組織債務的結果。

●在項目層面上，在 PoC 中，工具不兼容、缺乏定期數據訪問、數據質量缺陷或其他可能的失敗原因之一被廣泛忽視，應被視為組織債務

產生這樣的債務并不一定是壞事——它可能是有用的，甚至是必要的，例如，如果需要非常快速地交付 PoC。但如果發生了此類債務，人們需要意識到不斷增加的成本，確保其值得帶來的好處，并應該有一個償還計劃。

4. 在設計或更新數據生成流程時咨詢數據科學家

大多數公司已經擁有大量數據，并且這樣做已經很長時間了。然而，傳統上收集的數據通常并不意味著用來創造價值。相反，它被保存用于報告或監管目的。因此，對于某些數據科學用例，許多組織只是沒有所需的數據（質量）。不幸的是，有時可以在 PoC 環境中克服這個問題，很可能使用不適合在生產中應用的手動方法。盡管如此，對于戰略用例公司可能希望在其數據基礎上開展工作以實現這一目標。如果是這樣，或者如果數據生成過程因其他目的而被重新設計，請記住在設計這些過程時咨詢數據科學家和工程師！

例如，如果汽車、機器、物聯網設備、電梯等中包含新傳感器，以便收集用于記錄目的的數據，精通數據的同事可能會對數據應該是什么樣子有一個或兩個想法（頻率、測量等）以促進預測性維護用例。數據科學家的這些要求也將對業務案例產生影響。例如，如果需要為與數據科學無關的一個目的收集數據，但可用于三個數據科學用例，那么增加測量頻率可能是可行的。

5. 像投資任何其他有價值的能力一樣投資數據治理

每個曾經處理過數據的人都會知道，通常最大的障礙是數據質量（例如，大量 N/A 字段、難以置信的值等）和可用性（例如，從其他部門獲取數據、很少觀察、變量等）。部分原因是，當公司的數據生成流程到位時，它們并不是為了收集數據來實施數據科學用例而設計的。然而，更重要的是，這是由于缺乏或糟糕的數據治理，即主動管理數據以確保公司的可用性、可用性、質量和安全性。作為關鍵的推動者，而不是一個閃亮的流行詞，數據治理所受到的關注和資金比探索“人工智能算法”要少得多——這是不幸的。

雖然在用例的原型設計階段，由于缺乏數據治理而帶來的一些問題仍然可以得到緩解，但這些問題通常在部署階段變得非常緊迫，以至于危及用例進入生產。例如，在開發階段，數據中的質量問題通常可以手動糾正（例如 N/A 值的插補），但自動化此類解決方案通常要困難得多，因為需要考慮所有意外情況。或者，一種數據產品可能在一個市場中完美運行，但由于缺乏必要的數據而無法推廣到其他市場。

因此，糟糕的數據治理會導致數據科學用例的整個生命周期出現問題。

由于數據質量不佳，許多試點在開發階段就會失敗。但糟糕的數據治理帶來的后果在部署階段更為嚴重。

6.檢查項目并將其嵌入總體數據策略中

暫時拋開所有復雜的技術和部署過程的細節：數據驅動型組織的基本資產是從數據中創造價值的清晰愿景和戰略。其核心表現之一是領導者如何獲取正確的數據以實現其戰略目標。

谷歌通過街景程序收集世界上每條街道圖像的努力就是一個生動的例子。街景作為該公司開發自動駕駛汽車的早期步驟的衍生產品而誕生。該公司很早就意識到，這種對數據收集的投資所帶來的好處遠遠超出了為地圖用戶提供更好的定位。在 Google 創始人拉里·佩奇 (Larry Page) 和謝爾蓋·布林 (Sergey Brin) 領導的一項倡議中，街景成為 GoogleX 部門內的第一個項目，該部門負責托管該組織的“登月項目”。與此同時，街景圖像不僅被用來在自動駕駛汽車方面取得比任何競爭對手更快的進展，而且也大大改善了地圖。

所有行業都存在相同的基本機制：為了從先進的數據科學和人工智能用例中受益，有必要對數據獲取進行戰略投資。例如，Vorwerk 將建立一個實時數據管道作為首要任務，該管道收集和聚合全球超過 150 萬臺相連的 Thermomix 設備產生的數據。此外，他們還投資了最先進的本地和云端基礎設施。現在，他們可以通過各種高級用例來利用這些投資。

不幸的是，反之亦然：許多數據科學項目失敗是因為可用數據使它們不可能實現。再加上頻繁報道對人工智能潛力的高期望，這是通往失望的捷徑。我們當然相信數據創造價值的潛力。與此同時，我們一次又一次地看到數字化必須先于數據科學。當數據基礎還不存在時，嘗試實現高級用例是沒有意義的。相反，評估每個功能的數據準備情況并制定總體數據策略。首先關注容易實現的目標，然后將用例實施的傾向反饋回來以引導戰略重點。通過同時為更高級的用例奠定基礎并執行您的組織已準備好的用例來創建反饋循環。這樣，您將能夠保持高昂的士氣，并逐步致力于每個人都在談論的未來人工智能用例。

小結

我們研究了目前許多數據科學項目在部署階段失敗的原因。我們將部署定義為將數據科學 PoC 或試點結果轉變為可操作的數據產品并集成到業務流程中的階段。我們研究了數據科學用例的不同形式的技術部署，并確定了五個關鍵挑戰：

(1) 數據可訪問性和/或質量不足以促進可持續價值創造。

(2) 數據隱私和安全問題阻礙了擴展。

(3) 沒有足夠的數據和機器學習工程師來幫助部署數據科學家的成果。

(4) 在許多公司中，業務、數據科學和IT部門之間存在很大的組織鴻溝。

(5) 技術格局正在快速發展，企業 IT 尚未準備好運行創新和數據實驗室中使用的技術。

我們進一步分享了克服這些挑戰的最佳實踐，并使數據科學項目更接近創造真正的價值：

（1）擁有數據工程師。

(2)在跨學科團隊中工作

。(3)仔細權衡技術和組織債務的成本和收益。

(4) 讓數據科學家參與數據生成過程的設計。

（5）實施良好的數據治理。

(6) 確保項目有助于更大的數據戰略，并盡早為高級用例奠定基礎。