前言
做了一個儀表板。
為了讓大家每天都會看，我還透過 Email 和 Slack 做了每日推送。
……可是，沒有人看。
明明把原本零散的資料整合起來，好不容易做成了容易閱讀的儀表板。
這幾個月到底是在忙什麼啊。
有類似經驗的人，其實意外地不少吧。
當然，儀表板不是沒有意義。把複雜的資料整理、視覺化，讓人能掌握「現在發生了什麼」，這件事本身就很有價值。
只是，儀表板也有極限。
那就是，它本質上是用來「看」的。
為什麼儀表板會變得沒人看
儀表板對於察覺異常很有效。
例如，像下面這些變化，都可以透過儀表板掌握：
- 營收下滑
- 庫存不足
- 廣告效率惡化
有了儀表板，就能注意到這些異常。
但問題是後續。
察覺異常之後，實際的行動通常是在別的地方進行。
- 用 Slack 聯絡負責人
- 開啟 Salesforce 確認商機
- 用 Teams 安排會議
也就是說，儀表板可以作為「確認狀況的地方」，但不是「推進工作的地方」。
只會看一下就結束的東西，不會被納入日常工作。
不會被納入日常工作的東西，最後就會慢慢沒人看。
什麼是本體論（Ontology）
這時候重要的概念，就是在 Palantir 脈絡中常提到的「本體論（Ontology）」。
Palantir（帕蘭提爾）是一家美國公司，為企業與政府機關提供軟體，用來整合零散存在的資料，並將其連結到決策與業務行動。近年來，它也因為提供將生成式 AI 實際導入業務的基礎平台而受到關注。
這裡說的本體論，並不只是把資料整理得很漂亮的機制。
它是把現實業務中會使用的「客戶」「商機」「產品」等詞彙，以及它們之間的關係，也能在數位世界中處理的一種形式。
更具體地說，就是把公司日常使用的「客戶」「商機」「產品」等概念，定義成資料中的物件，並把它們之間的關係、規則，以及可操作的行動一起整理起來，這就是本體論。
接下來詳細看看。
數位世界與現實世界之間的落差
首先要理解的是，現實世界與數位世界之間存在很大的落差。
在現實世界中，我們是以「客戶」「商機」「產品」這類單位來認知事物的。
但在數位世界，特別是資料庫的世界裡，資訊是以資料表為單位管理的。
例如，就算只是「產品」這個概念，在資料庫中往往也會拆成：
products資料表product_categories資料表product_images資料表prices資料表orders資料表inventory資料表
等等。
如果是工程師，或許可以把它們 JOIN 起來，重新組合成「產品」這個資訊。
但業務人員平常想的「產品」，不是一堆資料表的集合。
他們認知的是由 商品名稱、類別、圖片、價格、負責部門、銷售通路 等資訊組成的一個整體。
也就是說，業務思考的單位與資料庫保存的單位之間存在落差，這就是資料活用變得困難的原因。
本體論是以業務的單位重新組織資料
本體論就是用來彌補這個落差的。
它不是直接把資料表結構展示給人看，而是依照現實業務中所認知的單位，重新組織資料。
例如，定義一個「產品」物件，並在其中串連 商品名稱、圖片、類別、價格、庫存、相關訂單 等資訊。
如此一來，業務人員就算不知道資料庫的表結構，也能透過平常熟悉的「產品」概念來理解資料，並在需要時進行更新。
另外，前面一直寫「透過 JOIN 資料表來建立物件」，但實際上的資料來源不一定只來自同一個資料庫中的資料表。
例如，就算只是「客戶」這個物件，也可能是由以下不同系統的資訊組成：
- 核心系統中的客戶主檔
- Salesforce 的商機資料
- 支援工具中的詢問紀錄
這種跨越多個系統組成一個物件的方式，才更接近本體論的核心。（如果只是同一個資料庫裡的資料表 JOIN 起來，工程師自己做 JOIN 就好了。）
物件是透過關係性串起來的
到目前為止，我們談的是把零散的資料整理成「產品」「客戶」這種業務上的單位。
但現實中的業務概念，並不是各自獨立存在的。
「產品」有「負責部門」，也會有「訂單」關聯。
「客戶」有「商機」，而商機又有「負責人」。
我們平常理解業務時，也包含了這些事物之間的關係。
在本體論中，也會表現出這種關係。
不只是單獨定義物件，而是把物件之間用連結（link）串起來。
例如，用連結把 客戶 物件和 商機 物件串起來，把 商機 和 負責人 串起來，把 產品 和 訂單 串起來。
如此一來，現實業務中的「這筆資料和那筆資料，是用這樣的關係連在一起」的結構，就能直接反映到資料層。
而這種物件之間透過連結相互串接的特性，正如接下來要說明的，會產生很大的效果。
一個變更會影響到連動的所有部分
本體論的強大之處，最容易看出來的場景，像是「負責人交接」。
假設業務人員調職或離職，某個客戶的負責人換成了別人。
「更換負責人」聽起來很簡單，但把實際要做的事列出來後，會發現需要變更的地方多得驚人。
- Salesforce 中進行中的商機指派
- 發送給客戶的定期報告寄件人與收件人
- Slack 通知與提及的對象
- 客服窗口與郵件轉寄設定
- 合約書、訂購單上記載的負責人姓名
- 儀表板中的「依負責人」彙總，以及目標、配額的分配
更麻煩的是，這些資訊散落在不同系統裡。
而且大多數情況下，在交接剛發生、最忙亂的時候，只能依靠口頭交代或備忘錄，一項一項手動修改。
結果會怎樣？
幾乎一定會漏掉某些地方。
客戶還在一直寄信給已經不在職的負責人。
定期報告還持續寄給前任。
重要通知在沒有人注意到的情況下默默流過去。
這與其說是個人疏失，不如說是結構性的問題。
「這個負責人對應到哪些客戶、哪些商機、哪些報告」這種關係性，沒有在任何地方被統一管理。因為這些關係只存在於前任腦中。
有了本體論之後，這個結構就會改變。
負責人、客戶、商機、合約、報告設定、通知設定，都會被定義成各自的物件，並且透過連結彼此串接。
重點在於：「這個負責人關聯到哪些客戶、哪些商機、哪些合約、哪些報告」這些關係，不是存在人的腦中，而是明確存在於資料層。
在這種狀態下，交接時要做的只有一件事：
更換 負責人 的指派。如此一來，連動的部分也會一起更新。
- 商機指派會切換
- 定期報告的寄件人與收件人會更新
- 通知的提及對象會變更
- 儀表板中依負責人的彙總也會自動變正確
負責人不需要一一記住要去修正哪個系統、哪個畫面。
只要執行「更換負責人」這個業務操作，相關部分就會完整更新。
這裡發揮作用的，就是本體論把物件用連結串起來的特性。
原本零散的資料，因為以業務上有意義的關係串接在一起，所以一個變更就能毫無遺漏地影響到連動的所有部分。
本體論會成為公司整體的共通語言
另一個很重要的點，是本體論會成為公司整體的共通語言。
在公司內部，同一個詞有時會被不同部門用來指不同的意思。
例如，「營收」這個詞，不同部門的定義就不一樣。
業務可能把「成交金額」稱作營收，會計可能把「依會計準則認列的金額」稱作營收，行銷則可能把「透過活動產生的購買金額」稱作營收。
在這種狀態下開會，對於「這個月的營收是多少」這種簡單問題，不同部門會拿出不同數字。
這時候，問題不是哪個數字對。
多半真正的問題是，大家看的不是同一種營收定義。
將曖昧的詞語分解成業務上可以使用的定義
建立本體論後，就能整理這種曖昧性。
不要直接處理「營收」這個曖昧詞，而是例如拆成以下定義：
・業務營收 = 受訂金額
・訂單營收 = 訂單確認金額
・會計營收 = 依會計準則認列的金額
・廣告歸因營收 = 與特定活動相關的購買金額
這樣一來，大家就能用相同的定義，看著相同的對象來討論。
即使各部門使用的應用程式不同也沒關係。業務需要商機管理，行銷需要活動分析，會計需要帳單與營收認列的應用程式。
重點是，這些應用程式在背後都連到同一個客戶、同一個產品、同一個商機、同一個合約、同一種營收定義。
也就是說，本體論不只是資料整合，也不只是視覺化工具。
它是把現實世界的業務轉換成能在數位上處理的粒度，賦予共同意義，並且能在其上執行業務行動的機制。
AI 時代的本體論
本體論之後的、會學習的業務基盤
到目前為止，我對 Palantir 脈絡中的本體論強大之處，是這樣理解的。
不過，這篇文章想思考的，不只是「本體論很厲害」「Palantir 很厲害」而已。
更想思考的是，這種想法要如何和 AI 時代的業務改善接起來。
透過本體論，公司內的 客戶、商機、產品、營收、施策，會以業務上有意義的單位被整理好。
這對 AI 來說也很重要。
因為 AI 若要對業務提出有意義的洞察，不能只是能存取大量資料表就夠了。
- 「什麼對應到什麼意思」
- 「哪些資料對應到哪些業務概念」
- 「對哪些對象，可以執行哪些行動」
只有把這些業務脈絡整理好，AI 才有可能不只是做數值摘要，而是提出能改善業務的假設。
AI 只在單純的儀表板上是很弱的
AI 在單純的儀表板上，發揮不了太大作用。
當然，它可以摘要數值增減，或偵測異常值。
但這樣還不夠強。
真正有價值的是，AI 能理解業務上有意義的物件，從它們的關係中找出模式，並提出具體的業務改善建議的時候。
例如，假設銷售活動的資料已經在本體論中整理好了。
客戶、產業、首次商談、提案書、提案內容、價格說明、後續跟進、負責人、成交、未成交原因 等，都被定義成各自有意義的物件。
在這種狀態下讓 AI 分析，可能會得到像下面這樣的洞察：
- 「在首次商談後 7 天內，寄出有圖解客戶既有作業流程的提案書的案件，成交率比平均高 23%」
- 「相對地，在第二次商談前就進行價格說明的案件，未成交率較高」
- 「在特定產業中，若用現場工時減少來說明，會比用 ROI 來說明更容易成交」
這類洞察，從單純的營收儀表板很難直接看出來。
因為不能只看營收上升或下降、商機數增加或減少這些結果，還必須去看背後的行為與脈絡。
誰、對哪個客戶、在什麼時機、提出了什麼提案，最後結果如何。
只有把這些資訊以業務上有意義的形式整理好，AI 才能找出模式。
不要完全相信 AI 的提示
同時，這裡很重要的一點是，不要把 AI 的提示直接當成答案。
AI 很擅長找出 "相關性"。
但是，它不容易判斷這是不是 "因果"。
「在首次商談後 7 天內寄出提案書的案件成交率較高」，但這不代表真的就是提案書速度造成的。
也許只是本來就意願很高的客戶，比較快要求提案書。
也可能只是剛好優秀的業務人員有這樣的行為。
又或者，這個模式只對特定產業或特定商品有效。
所以，AI 的提示一定需要人類介入。
將 AI 的提示養成組織的形式知識
接下來這一步，我認為才是 AI 時代本體論應用最有趣的地方。
對 AI 找出的模式，由現場人員或管理者來判斷。
「⭕️ 這個看起來可信」
「❌ 這個看起來只是巧合」
「❌ 這個可能會造成誤解，所以駁回」
像這樣，讓人類審核 AI 提出的提示，並且區分哪些可用、哪些不可用的機制是必要的。
管理者用 Approve / Reject 的方式也可以，現場人員用 Good / Bad 之類的回饋也可以。
重點是不讓 AI 的提示只停留在一次性的自動生成評論。
Good 較多的提示，會被其他團隊或類似案例參考。
Bad 較多的提示，則降低顯示頻率。
現場補充的評論，會用於下一次分析或提案。
如果形成這樣的循環，AI 的提示就不再只是報表，而會逐漸接近經過組織驗證的知識。
也就是說，AI 找出假設，人類以業務脈絡判斷，只留下可用的知識。
透過這個流程，現場的隱性知識會逐步轉化為顯性知識。
儀表板之外的東西
到了這一步，資料活用就不再只是「分析」而已。
AI 從業務資料中找出假設。
↓
人類驗證這個假設。
↓
有效的內容會留下來，成為業務規則或建議動作。
↓
不太合適的內容則降低顯示。當這樣的循環建立起來後，資料活用就不只是視覺化，而會更接近一種讓業務不斷學習的機制。
儀表板是用來看現在發生什麼事的。
但結合 AI 與本體論的業務基盤，不只能看「發生了什麼」，還有可能處理「下一步該試什麼」以及「這個判斷到底有沒有效」。
總結：儀表板之外的、會學習的業務基盤
儀表板是讓資料可視化的強大手段。
但是，只有看得到，業務是不會改變的。
真正重要的是，能夠用業務語言理解資料，並且直接連結到判斷與行動。
本體論就是為此而存在的基礎。
再加上 AI，便能建立一個流程：從業務資料中找出假設、由人類驗證、再把有效的知識累積到組織裡。
儀表板之後真正需要的，不只是看資料的機制，而是讓業務本身一點一滴變聰明的機制。
最後
這篇文章所描述的那種「不把資料可視化就結束」的機制建構，現在仍然有很多公司在摸索階段。
Sapeet 也正在運用資料與 AI，打造讓產品與業務變得更好的機制。
不只是做儀表板，而是思考如何把資料融入業務、如何連結到行動、如何持續改善。
我們正一邊面對這些主題，一邊推進產品開發與業務改善。
這個領域還沒有固定答案。也正因如此，才有空間讓我們自己立下假設、嘗試、再改善，打造更好的機制。
如果你也對這類主題有興趣，歡迎一起來工作。
原文出處：https://qiita.com/KYoshiyama/items/52dc298122587969b39c
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
