提出問題的重要性 Bob RogersIntel 大數據解決方案首席資料科學家2016 年 6 月

IIA 研究總監 Daniel Magestro 主持訪談

為分析過程指引方向

提出問題的重要性：為分析過程指引方向 2

當你開始了解一個企業組織時，是如何判斷一個分析團隊或計畫的成熟度？

首先就是要詢問他們現在使用分析數據的目的為何。他們有些什麼疑問？他們想要提出什麼樣的問題？而他們使用的資料又是從哪裡來？接下來就是詢問資料的形狀：他們是否使用了非常嚴謹控管的結構化資料？有沒有加入任何更廣泛的資料？這些資料是否來自公司不同地點？或者反過來說，他們公司裡是否存在因為公司規定或技術限制而無法使用的資料？所以最初的問題是有關於他們想從資料中瞭解什麼。瞭解這一部分之後，接下來得釐清的就是關於他們想要回答哪些疑問。

這個做法主要是為了掌握背景資訊嗎？還是這個做法本身就已經展現出他們的成熟度，讓你可以開始評估？

這絕對可以用來評估他們的成熟度。因為如果他們沒有妥善處理非結構化資料，就不會知道需要如何在資料中心裡建置這些資料的模型。在以前做分析的方法裡，經理人會說：「我要一份 X 的報告；我要知道我們賣了多少件商品，或是特定事業群的各品項型號與不同區域從年初至今的銷量和營收。」然後分析師就會開始做查詢，回報結果。這一切都需要系統裡的資料已經小心整理成資料表形式，要已經結構化的資料。然後把資料表的行列組合成某種綱要。分析師常要面對的挑戰是「如果我能夠存取那邊那項資料，真的就能為這個問題提供更好的答案。」而「那邊那項資料」可能會是別的資料庫產生的，或是不同業務單位擁有的系統，但總之讓分析師組合起來的話能夠提升分析品質的資料。問題就在於他們拿不到那項資料。

話題概覽Intel 的大數據解決方案首席資料科學家 Bob Rogers 和國際數據分析研究所 (IIA) 的研究總監對談，討論在評估分析企業組織成熟度之時提出問題有多麼重要。

提出問題的重要性：為分析過程指引方向 3

很多年來，分析師都一直在說因為無法存取資料而沒辦法做到他們心目中的理想分析。因此大數據和 Hadoop* 基礎架構登場，還有隨之而來的 Spark* 和 Apache Flink* 以及 NoSQL 資料來源，像是 Cassandra*。突然之間，他們能夠把資料組合成為資料中樞或是數據湖，把公司各處的資料都集中，就好像是到了天堂一樣。於是企業踏上這個旅程，決定要建立一個數據湖，然後各種見解會像泡泡一樣自己從湖中冒出來。但他們最後發現，即使他們覺得這些資料裡藏著他們一直缺少的東西，但手上拿到的還是更多雜亂無章的問題。因為使用關聯式儲存庫裡的資料時，尤其是企業資料庫的情況下，你還是受限於特定的形狀和結構。

能將資料放進資料中心而不需要嚴格遵守非常具體的關聯式結構，其實並不代表你不想要資料就緒。所以回到你的問題，如果我問他們：「你們資料中心或資料中樞裡這些非結構化資料是怎麼建模？」通常他們只會一臉空白看著我。他們不懂我在說什麼。這時你就知道必須回頭教導他們什麼是資料建模，讓他們瞭解每一組資料之間的關係，然後才能開始談分析。

「 除了要擁有正確的技術組合，很重要的是有能夠適度用言詞表達的人。」

提出問題的重要性：為分析過程指引方向 4

藉由提出問題瞭解成熟度之後，你是如何區分或命名各種不同程度的成熟度？

我並沒有正式的名稱，但通常是用最初的商業智慧能力來分辨。假設分析數據像許多小島一樣分開，不同的團隊保有各自的資料，或許還會各自保有內部的資料庫。這些甚至可能是在同一台機器上執行，像是同一台桌上型電腦。它們可以在本機做計算，可以回答像是「我們團隊從年初到上一季結束為止有多少營收？」這種問題。然後成熟度高一階的就會有自動化機制，能比較快速載入資料。這時他們就能夠問：「我們團隊從年初到上個禮拜為止有多少營收？」他們縮短了時間差，但仍然只看自己的團隊。

再來就是基本的商業智慧企業資料庫階段，能開始彙整和組合複數團隊的資料到單一個儲存庫，甚至是複數業務單位的資料。這時他們就能回答：「從年初至今的銷量和營收有多少？」跟之前「我們團隊到上禮拜為止各品項型號和地區的數據」分析的差異就在於我們能夠開始彙整更多處的資料了。這基本上就等同是用 SQL 查詢關聯式企業資料庫。再往上一個階段就能夠詢問像是：「從年初到昨天營業時間結束為止，我們業務單位各品項型號和地區的銷量和營收有多少？」到這時，已經能夠使用目前的資料，但是仍然侷限於我們有存入資料庫的特定資訊，完全沒有任何彈性。就我的經驗來說，大概超過一半的企業組織是在這個階段。

接下來就是進階分析或進階營運分析的範疇，開始利用較高階的資料處理技巧，也開始能做歷史分析，讓我們能夠詢問像是：「在過去有哪些因素影響到我們公司的銷量和營收？」也可以更進一步詢問：「我們的客戶究竟是誰，又有什麼特徵？」這時不但能夠檢視每一季發生了什麼事，還能夠檢討究竟是什麼原因造成我們眼前的變化，然後這些原因又跟我們的銷售對象有什麼關聯。從這裡開始就要分成多個分支了。

一種是加入物聯網技術，這就有其本身的問題。例如貨運公司可能會想詢問：「包裹送到哪裡了？」這就是指企業能否以接近即時的狀態掌握包裹在物流系統中的所在位置。所以處於進階分析階段的企業組織已經擁有及時的分析能力，資料都維持最新狀態，分析技術也不是只有樞紐分析，可能會有些資料視覺化的能力。然後也會利用要素分析來瞭解是什麼要素影響著眼前的結果。這個階段的分析成熟度講究的完全都是因果關係。

接下來就是預測式分析。不但擁有基本的營運資料，更開始收集背景資料，而這些背景資料就常屬於非結構化資料。這裡我們就開始接觸到含有非結構化資料的及時資料分析了。像是人們都在談論什麼、網際網路上有什麼熱門話題、服務中心的動態等等，讓我們不但能瞭解熱門的話題為何，也能掌握其影響是屬於正面或負面。

漫談數據分析的範疇

提出問題的重要性：為分析過程指引方向 5

到這個階段 — 預測式分析的階段 — 通常已經是在詢問例如：「明年各品項型號應該會有多少銷量和營收？」所以講求的是預測。我的預測有多準確？而這是非常、非常重要的要點。進入預測式分析階段的企業組織不能光只是做預測，這很多年前就有了，甚至在商業智慧初期的環境就有；他們的重點實際是在於瞭解這個預測有什麼限制、又有什麼因素會影響它。然後他們也能回答像是：「我的顧客對我的產品和競爭對手的產品有什麼意見？」這真的就需要彙整許多不同種類的資訊了。

大多數企業肯定都還沒有達到預測分析的階段，但他們都已經以此為目標。所以在我大多數的對話當中，他們都能夠指出一些會影響業務的因素，然後想要知道這些因素會如何改變他們未來應該怎麼做。

然後在最後還有兩大類型：規範式分析和認知式分析。規範式分析是分析媒體界常常討論的東西。規範式分析的概念是分析數據其實會自動促成決策，給你資訊讓你知道該做什麼。這裡提出的問題就會像是：「在這樣的銷量和營收預測狀況下，該如何訂定新產品開發的重要性？」也就是說：「我現在不光是知道關於我認為未來會發生的事情，而且還是根據我的各種產品和產品線的漏洞知道未來可能會發生的事情；再來我該如何能能有效接觸到顧客？」這種分析是用來補足未來計畫中的空白。所以這並不單純是我對於既存商品的預測，也讓我知道目前的計畫當中缺少了什麼，能幫助我決定該如何著手處理各種選項。

我覺得真正的價值是在於詢問：「我們該如何利用預測和模擬所提供的資訊來輔助人為的決策？」然後物聯網的版本就會是：「我該如何管理車隊？包括哪些路線、哪些車種、哪種燃料和哪種駕駛模式，才能夠最佳化像是車輛壽命或年度營運成本，或是其他我想要改善的東西？」所以這個其實可以說是一種模擬遊戲：不同的選擇會有哪些結果、又有什麼能夠改變這些結果？

最後，認知式分析完全不同了，已經不是人在提問，而是分析系統在提問，然後自己回答！例如物聯網方面一個比較真實的例子就會是：「我的系統可以加入什麼測量標準或感測器來改善預測能力？」實務上，這真正的意義是讓分析系統的人機互動更流暢，並加入更有彈性的資訊。即使是在預測式分析，只要是從非結構化資料取得數值，就開始必須考量到所謂的信賴度。如果我們思考人類行為，會發現我們並不具體去思考一個數據正確與否的可能性。我們直接就做決定，或是列舉出多個選擇。

「 我並不認為有任何企業組織不應該追求預測式分析。」

提出問題的重要性：為分析過程指引方向 6

這種提問式的做法，重點是否偏向於評估「人」本身，而非程序或技術？

是的。我最常聽到的問題之一就是「該如何把我的團隊轉型成為能夠幫助我回答下一階段問題的團隊？」通常，這表示團隊裡有些分析師的技術背景不同。有些人可能來自統計學或數學背景，有些可能是電算學或較專門的 SQL 技術，也就是說完全就只受過訓練在關聯式資料庫做結構化查詢的人。只要根據他們各自能夠回答的問題，就可以把技能對應到問題，然後找出缺乏的技能或需要的訓練課程。這問題最終通常是變成：「我的團隊需要添加什麼樣的人才，或是該給他們什麼訓練課程才能讓他們回答下一階段的問題？」如果我是在預估、做預測的階段，然後需要有人能夠理解預測的準確度，那至少在這個階段是需要比較偏向統計學或資料科學背景的人才，因為預測準確度的計算其實是屬於統計機率方面的問題。

通常當團隊處理非結構化資料的經驗不足時，真正需要的是能夠帶來他處理非結構化資料的實際、具體經驗的人才，因為這有本質上的不同。你必須要開始考量到手上的這份資訊是否能夠用於你的應用目的。

各種不同技術的使用是如何融入於你對於成熟度的評估，或是如何妨礙或誤導你評估成熟度的能力？

這是個好問題。虛擬化就是一個很難判斷的地方，因為虛擬化如果應用得當，它其實能取代一些較成熟的分析數據。例如以舊科技營運的公司裡有一個很活躍的領導人才，在公司設立了資料科學的處理。他們組裝一套 150 個節點做真正大數據的基礎架構，然後彙整資料並且建模。事實上，這個例子裡他們原本沒有建模就直接彙整資料，結果搞得一塌糊塗。所以他們回過頭重新設計系統架構，確實幫進來的每一筆資料建模，藉此理解手上究竟有什麼資料並加上註解。他們為不同的產品組合建立資料模塊，並訓練分析師利用工具來製作無數據的互動式視覺以取代建置底層的機器學習和分析管道來評量當時在客戶端發生的事件。

除了要擁有正確的技術組合，重要的是有合適的人用言詞來傳達狀況，並且能夠視需要將言詞連結至分析數據。我認為這是資深數據科學家在團隊中最重要的責任：教導每個成員如何在分析數據當中傳達「人」的故事。

科技與人的角色

「 重點是在於瞭解公司是否正確認識數據和商業目標之間的關聯。」

提出問題的重要性：為分析過程指引方向 7

我們在 IIA 發現企業組織常會以最高階段的成熟度為目標，像是機器學習和認知式分析。這種做法是好的嗎？

我覺得認知式分析的意義其實是在於瞭解這些近似人類優異能力的功能如何能夠輔助人類或實務上取代人類。其實並沒有很多環境是把人腦換成電腦還能夠帶來很大價值的。大多數時候，用分析結果來幫助人們分析是最理想狀態。而這種狀態比較偏向於規範式的階段，介於規範式和預測式分析之間。我並不認為有任何企業組織不應該追求預測式分析。

有了規範式分析，你即可開始著手以正確的用法而產生的強大效益的技術。所以這是屬於成熟度的問題。公司的成熟度是否足夠建立良好的規範式分析能力，或是能夠確實發揮規範式分析而實際考量到數據分析本質上的不確定性？譬如說有些狀況下其實無法做可靠的預測，而你必須要能夠察覺自己正處於這些狀況中。

你不會想要發現自己花費龐大努力或投下大筆投資去賭九成隨機的預測。而演算法當然無法察覺這個狀況。它單純就只是計算出預測數值而已。用最成熟的演算法算出來的仍然只是個預測值，如果你運氣好，或許還會附送一個偏差值。但追求規範式分析的企業組織必須要注意這些分析數據究竟是否適用於實際業務，以及這些數據實際有多少價值。

另一方面，如果能夠測量出有什麼事情最可能影響未來結果，那便有了個起點可以開始思考；至少會是啟動自己決策思考過程不錯的起點。我覺得每家企業絕對都應該要能達到預測式分析的階段。然後幾乎每家企業都應該在合理的時間內達到規範式分析的階段，一步步瞭解每個階段的分析技巧和限制，提升成熟度，最後則把認知式分析視為值得更進一步研究的領域。

向前邁進

提出問題的重要性：為分析過程指引方向 8

對某些企業組織來說，這些問題或許無法現在立即回答，但是卻可以作為往後努力的方向。

可以。而且我覺得企業在著手準備下一代的經營時，必須把眼光放在下下一代。也就是說問題永遠在前方不遠處。從初期商業智慧進步到進階經營的階段，至少應該要開始考慮你未來預測式分析有哪些目標。

如果沒有長遠的考量，就會很容易開始說：「這風險太高了，我們以後不考慮進入下個階段。」像是進階經營分析。如果在障礙的另一端沒有這種長遠的誘因，就永遠跨不過障礙。我希望如果一個企業能夠看得見預測式階段的願景，這應該有助於突破他們對於既有基礎架構的恐懼。而且老實說，有趣的是他們並沒有發現整個查詢和報告系統其實能夠在大數據平台上運作。沒有長遠的願景，就很容易看到因避險心態導致企業停下腳步，無法朝分析技術的終極階段邁進。

生命中重要的並非回答問題，而是提出問題。所以我這 10 年來其實也完全改觀了，因為我發現提出好問題的效益遠遠勝過提供幾個有可能正確的答案。我覺得這很有趣，因為這整個提問的概念牽涉很多，真的有助於解開一些混肴和扭曲。

說真的，重點是在於瞭解公司是否正確認識數據和商業目標之間的關聯。最初的問題是：「你是用什麼策略決定應該要回答哪些問題？也請舉例一個要回答的問題。」得到問題之後，接著問：「你覺得有什麼資料擁有關聯性，而你又有什麼策略來將資料帶進分析之中？」

這個問題有個優點，就是它完全不依存於某特定技術，對不對？它的重點是「在你的理解當中，數據分析能夠做到什麼事情，而各不同的資訊之間又能如何組合？」然後下一個問題可能就是：「你採取什麼行動來訓練團隊或評估團隊，或是幫助團隊取得足夠能力執行專案？」無論他們用的是 Flink、Spark 或是 Hardoop，這些問題都讓你能確實理解他們的想法。

INTEL 展望規範式分析Intel 積極參與可信賴分析平台 (Trusted Analytics Platform，TAP) 計畫，一個為加速以大數據驅動的雲端原生應用程式開發而設計的平台。TAP 是可延伸的開放原始碼平台，讓資料科學家與應用程式開發人員部署解決方案時無需煩惱基礎架構的取得或平台設定，使企業能夠更輕易導入數據分析與機器學習。

Bob RogersBob Rogers 博士是 Intel 大數據解決方案的首席資料科學家，發揮他解決大數據與分析問題的經驗來幫助 Intel 打造世界級的客戶解決方案。加入 Intel 行列之前，Bob 原是醫療產業大數據分析公司 Apixio 的協同創辦人兼首席科學家。他認為正確理解病患的狀況、醫師的行為模式以及醫療服務網路系統的特性才能為未來醫療服務奠定紮實基礎，而大數據分析則是推動此改革的關鍵。

閱讀 Bob 在 Intel IT 同儕網絡的部落格。

關於受訪者

探索 INTEL 以及 IIA 的解決方案

擬定分析架構如欲發揮企業資料真正價值，必得先做許多決定。這當中並沒有一體適用的做法。建立分析系統之前，有幾個有助於專案成功的關鍵因素必須思考。

1 將資料儲存接近處理的狀態既可節省時間，也能節省傳輸成本。許多企業選擇將所有資料儲存於單一位置。

2 即時分析會產生不同的需求，可能需要不同的工具。例如必須考慮到資料量、格式和延遲。

3 存取控制項應適當對應至不同敏感度的資料。安全性的考量亦須能夠保護資料但不妨礙分析師存取。

9提出問題的重要性：為分析過程指引方向

• 發現數據分析如何促進創新，請造訪 intel.com/analytics 。 • 造訪 iianalytics.com/services/benchmarking 以進一步瞭解 IIA 的分析成熟度評估。

0616/AS/MRM/PDF-TW 334272-001

Copyright © 2016 Intel Corporation.保留一切權利。Intel、Intel 圖誌、Intel. Experience What’s Inside 圖誌和 Intel. Experience What’s Inside 是 Intel 公司及其子公司在美國和/或其他國家/地區的商標。 * 其他名稱與品牌可能業經宣告為他人財產。

與同事分享