「我們的 OT 和 IT 資料是分開的，想整合起來。」這是很多數位轉型專案的起點。常見的下一步是選一套平台，把兩邊的資料匯進同一個地方。
資料確實進了同一個資料庫。但一兩年後，原本想回答的問題——「這批品質異常和上游哪個製程參數有關」——往往還是回答不了。
問題出在：孤島不只一種，而換系統只解決了其中一種。
三種孤島
一、實體孤島
資料存在不同的機器、不同的網段，OT 網路和辦公網路之間隔著防火牆甚至物理隔離。這是最容易辨識的一種，也是唯一能靠建置解決的。
多數整合專案處理的是這一層。做完之後資料在同一個地方了，看起來問題解決了。
二、語意孤島
兩邊對同一件事的定義不同。
生產系統裡的「一批」，是投料的批；品管系統裡的「一批」，是檢驗的批。兩者的邊界不見得對齊。ERP 的「工單完成」是財務認列的時點，現場的「做完了」是實際下線的時點，中間可能差好幾個小時。
當這兩種「批」和兩種「完成」被放進同一張表用同一個欄位名，差異就消失在視覺的整齊裡。之後所有基於這張表的分析，都繼承了這個誤差。
這一層搬家解決不了。搬完之後，你只是把兩套不一致的定義放得更近。
三、責任孤島
這一層最少被談到。資料整合之後，誰有權定義欄位的意義？誰負責在製程變更時更新定義？誰決定某筆資料在什麼情況下不該被拿來做判斷？
如果這些問題沒有答案，那麼即使前兩層都解決了，資料的可信度仍然會隨時間衰減——因為沒有人負責維持它。
為什麼「先匯進來再說」通常不划算
把所有資料先集中、之後再處理語意，聽起來是合理的順序。實務上的困難是：脈絡在搬運過程中會流失，而且流失之後補不回來。
一筆數值離開原本的系統時，它的取樣方式、時間基準、當時的設備狀態、誰在什麼情況下輸入的——這些如果沒有一起被帶走，之後就只剩下數字本身。要重建，得回頭問人；問得到的前提是那個人還在、還記得。
這也是為什麼許多資料湖專案在第二年會遇到同一個困境：資料很多，但沒人敢用來做重要判斷。
另一種順序
比起「先全部搬過來」，另一種做法是從一個具體的問題出發，只連該問題需要的資料，並且在連接的當下就把脈絡帶進來。
例如先選定一個真實的追查需求：「某型號的不良率在特定班別偏高，想知道和哪些製程參數相關」。為了回答它，你需要知道哪幾個資料源、哪些欄位、它們的定義由誰負責、時間怎麼對齊。範圍小，但每一項都是完整的。
回答完這一個問題，你會得到兩樣東西：一個可用的答案，以及一小塊語意和責任都清楚的資料基礎。下一個問題可以站在它上面。
這比一次搬完再回頭整理慢，但它每一步都能被驗證，而且不會累積看不見的誤差。
X·Neurons 的角色與邊界
我們選擇的角色是連結而不是取代：不以全面替換 PLC、MES、ERP 或現場程序為起點，而是在既有投資之上建立可治理的連結，讓資料進入有理由、有責任的決策與行動。
目前所有 X·Neurons 能力都處於候選狀態，描述的是共同驗證中的預期行為，不是已發布、可直接採購的功能。企業智慧是我們的工作理論，不是已成立的科學；它的邊界寫在方法論頁面上。
需要說清楚的限制：語意定義無法自動產生，責任歸屬更不能由系統決定。這兩件事仍然需要組織裡的人做出選擇。工具能做的是讓這些選擇一旦做出，就能被明確記錄、持續沿用、並在改變時留下痕跡。
一個判斷題
如果你正在評估整合方案，有個問題可以快速看出它處理的是哪一層：
導入之後，當某個欄位的定義需要修改，流程是什麼？誰核准？既有資料怎麼標記？
如果對方的答案停在「可以改」，那它處理的是第一層。如果答案包含了誰負責、怎麼留痕、既有資料如何處置，那它至少想過第三層。