這種脫節不僅僅是令人惱怒，它還損害了業務中通常產生大部分利潤的部分。在許多行業中，60% 或更多的收入來自服務，其利潤遠高於原始設備銷售。然而，產品資訊的數位骨幹在很大程度上仍然是由工程部門設計且為其服務的。

越來越多的工業公司開始質疑這種模式。在 Field Service Forum 2026 – Power of 50 上，達索系統 (Dassault Systèmes) 副總裁 Philippe Bartissol 分享了這一新觀點：PLM 不應再是一個僅由工程部門擁有且恰好儲存某些產品數據的工具。它應該是一個服務驅動的骨幹，在整個真實生命週期中管理安裝基數 (installed base) —— 從概念到回收，包括數十年的現場服務、改造和除役。

傳統的 PLM 從未被設計成延伸至工程和製造之外。一旦機器出貨，PLM 中的「L」（生命週期）實際上就結束了。服務團隊隨後只能利用 ERP、CRM、現場服務工具和本地電子表格來臨時應對。

大多數組織仍將 ERP 視為管理安裝基數的主要系統。產品識別碼、配置甚至技術細節通常被埋在 ERP 表格中。這造成了幾個問題：

• 產品結構與服務結構脫節。

• 工程變更傳遞到服務端的速度緩慢或根本無法實現。

• 備件目錄與現場實際情況脫節。

• 安裝基數數據在不同區域和團隊之間不一致。

另一種選擇是將 PLM（包括 CAD 和 3D 模型）視為不僅僅是用於新產品開發，而是用於現場每個資產整個生命週期的骨幹。在這種模式下，PLM 成為產品和服務數據的儲存庫，而其他系統則從中獲取數據。數據模型延伸至工程之外，用以描述：

• 實體產品（機器、模組、組件）。

• 服務產品（合約、維護方案、改造）。

• 同一資產的工程視圖與服務視圖。

• 每台機器的實際序號配置。

關於 PLM 的決策不能再僅由工程部門決定。服務領導者需要成為 PLM 策略、選擇和治理的核心，因為他們對安裝基數數據、備件和現場流程的需求定義了生命週期的絕大部分。

工程視圖 vs 服務視圖：服務真正需要的數位分身

數位分身 (Digital twin) 經常被抽象地討論，但對於服務組織而言，當你區分同一資產的兩種視圖時，這個概念就變得具體了。

工程視圖描述產品是如何設計和構建的：完整的物料清單 (BOM)、所有結構部件、設計意圖、公差和模組。此視圖對於根本原因分析、複雜的改造以及向研發 (R&D) 提供回饋至關重要。

相比之下，服務視圖專注於維護和修理過程中真正重要的事情。這需要一個專用的服務物料清單 (SBOM)，其：

• 僅包含與服務相關的備件、消耗品和組件。

• 將部件分組為反映實際現場操作的服務套件 (service kits)。

• 連結至服務工作指令、工具和安全資訊。

• 與 3D 模型綁定，使技術人員和規劃人員能夠將工作視覺化。

沒有開發工程師能定義出實用的服務套件。只有服務團隊知道哪些部件總是需要一起更換、在實際條件下什麼會失效，以及如何最大限度地減少現場訪問次數。如果 PLM 不支持具有 SBOM 的獨立服務視圖，服務團隊將被迫維護自己的結構和目錄，與工程部門脫節。

現代 PLM 平台正開始通過允許兩種視圖共存並保持同步來彌補這一差距。在新產品開發期間，工程師可以定義產品結構，而服務團隊則在同一環境中定義 SBOM、服務流程和基於 3D 的工作指令。隨後，產品變更將根據設計流向兩種視圖。

將 PLM 延伸至安裝基數

服務驅動型 PLM 的真正考驗不在於它對通用產品的支持程度，而在於它能多精確地代表現場的每個安裝資產。

對於生產少量高度定制機器的公司來說，需求很明確：每台機器都是獨一無二的，服務取決於了解其確切的配置、位置和修改歷史。在這種情況下，PLM 現在可以為每個序號儲存特定的數位分身，包括：

• 工程視圖：設計狀態 (as-designed) 和構建狀態 (as-built) 的結構。

• 服務視圖：維護狀態 (as-maintained) 的 SBOM 和服務套件。

• 位置與客戶：資產運作的地點。

• 歷史記錄：問題、干預、改造以及即將進行的活動。

這實現了一種不同的工作方式。在訪問之前，規劃人員或調度員可以打開安裝基數控制面板（install base cockpit），查看該站點機器的實際數位分身（twin），而非通用模型，而是特定的配置。接著，他們可以選擇正確的備件，驗證工作指令，並為技術人員做好充分準備。

對於大量生產的製造商，這種方法更具選擇性。並非每個單元都需要量身定制的分身。相反地，安裝基數可以根據數據豐富程度和業務價值分為不同的類別：

• 僅已知高階參數的舊設備。

• 具有部分結構且文件有限的中期資產。

• 具有完整物料清單（BOM）和 CAD 數據的近期安裝設備。

每個類別的處理方式各不相同：有些可能證明重建部分分身是合理的；其他則可以在更通用的層級上進行管理。關鍵在於將安裝基數視為一個結構化的組合，而非歷史的偶然。

服務驅動的變更管理與備件

在 PLM 內部將服務與工程聯繫起來，重新塑造了變更管理。在許多組織中，當工程部門更改組件時，服務部門得知消息較晚，甚至完全不知道。備件目錄在數月後才會更新，如果真的有更新的話。

透過共享數據模型，產品變更可以在單一流程中跨越工程、製造、服務方案、服務物料清單（SBOM）和安裝基數記錄。當變更獲批後：

• 工程視圖得到更新。相關的 SBOM 和服務套件隨之調整。

• 備件目錄條目自動修訂。

• 透過序號識別適用的安裝資產。

• 服務團隊可以規劃改造或主動更換。

至關重要的是，PLM 現在必須包含備件目錄及其發佈的明確對象，而非將其視為外部文件，而是與分身綁定的結構化數據。這減少了工程圖紙、服務手冊與技術人員在現場實際看到內容之間的不一致。

在隱性知識退休前將其捕捉

另一個壓力點是勞動力人口結構。許多現場技術人員即將退休，而他們的許多專業知識仍是隱性的：存在於個人經驗、本地筆記和非正式實踐中。如果公司希望維持服務品質和增長，將其轉化為顯性知識並非可有可無。

問題在於這些知識應該儲存在何處。如果每個職能部門都有自己的記錄系統，現場知識就有被分散或丟失的風險。

服務驅動的 PLM 提供了一個答案：將知識直接以結構化數據的形式嵌入到分身中：

• 分步驟描述的服務流程，通常以 3D 形式呈現。

• 每次操作所需的工具和條件。

• 編碼為工作指令的實務建議。

• 當技術人員遇到新情況時，可創建問題或變更請求的反饋迴路。

人工智能可以發揮輔助作用，但前提是底層數據必須是結構化且可靠的。一個新興的應用場景是在訪問後攝取技術人員的報告，並自動建議更新數位分身。隨後由調度員或中央協調員驗證更新。隨著時間推移，分身將反映資產的真實狀態，而無需現場技術人員付出額外努力。

這更多是關於紀律嚴明的數據管理：一致的模型、清晰的工作流程和明確的所有權。一旦基礎設施就緒，AI 就可以在極少的人工干預下，大規模地幫助維持準確性。

服務領導者接下來應該做什麼

這一轉變的一個啟示是，PLM 策略不再僅僅是後台工程部門的關注點。它是服務收入、獲利能力和客戶滿意度的核心槓桿。

因此，服務領導者應該：

• 堅持成為 PLM 決策和路線圖的核心利益相關者。

• 在選擇或擴展工具之前，定義關於安裝基數管理、SBOM、服務套件和工作指令的需求。

• 挑戰「ERP 或臨時工具是現場產品和服務數據自然存放地」的假設。

• 從明確的範圍開始：要麼是從第一天起就得到正確管理的全新產品線，要麼是投資報酬率（ROI）明確的現有安裝基數優先片段。

• 設計流程，規定現場問題如何觸發對分身的結構化更新，以及在相關情況下如何觸發對工程的更新。

目

標不是在一夜之間重建每個資產的歷史，而是建立一個連貫的、由服務主導的數位線路（digital thread）以實現未來增長。一旦 PLM 擴展到涵蓋整個生命週期（包括數十年的服務、改造和生命週期結束），製造商就可以將服務視為長期獲利的主要引擎。