ERP 現代化：SAP 搭配 ServiceNow

以 SAP 與 ServiceNow 推動 ERP 現代化，意思是讓每個平台去做它最擅長的工作，並把它們好好連起來。SAP S/4HANA 負責結構化的交易：財務、採購、庫存、薪資。ServiceNow 負責周邊的工作流程：受理、核准、例外與服務請求。SAP Integration Suite 與 ServiceNow IntegrationHub 把兩者串起來。本指南寫給正在規劃從 SAP ECC 或早期 S/4HANA 系統進行現代化的 CIO、財務長與企業架構師。內容涵蓋依職能劃分的工作分配、AI 的定位、分階段的路線圖與常見陷阱。先看各職能的表格，再看路線圖。

ERP 現代化幾乎出現在我接手的每一個專案裡。我合作過一些仍在跑 SAP ECC 的公司，在本該多年前就退役的環境裡管理財務或營運。有一位物流客戶，光是核准一項小小的流程變更，就得經過四次人工交接。我們把 SAP 與 ServiceNow 串起來，週轉時間與可視性的差別立刻顯現。

我常看到的錯誤：以為 ERP 現代化就是升級到最新的 SAP 版本。如果您的系統彼此不對話，您只是把問題搬到了一個更新的介面上。資料困在各自的孤島裡。團隊不再信任工具。大家忙著追問題，而不是解決問題。

很多團隊以為自己已經現代化了。實際上，他們只是升級了。差別會在日常工作中顯現。

現代化的意思，是重新思考您的系統今天如何支援業務，而不是十年前它們被設計成怎麼運作。它牽涉架構、流程、資料、整合與使用者體驗。

CIO 常問我：「所以這是要搬上雲端，還是要換掉我們的 ERP？」有時兩者都是，但很少一次全部做。真正的現代化，通常始於 ERP 無法再隨業務擴展、摩擦變得看得見的時候。

中東一家消費性商品客戶當時還在跑 SAP ECC。財務部門把時間都花在清理錯誤資料上，報表落後於營運。我們一開始先重新評估導入本身：不只是技術，還有流程是否仍符合業務的運作方式。接著是主檔資料。然後是自動化：SAP 能在內部處理哪些，ServiceNow 又能在哪裡補上缺口，特別是核准、升級處理與流程追蹤。這個順序，讓管理階層有了一份計畫、一條時間軸，以及可以追蹤的成果。

現代化很少意味著把一切拆掉重來。更常見的是，企業保留現有運作良好的部分，在它周圍進行現代化。這正是 SAP 與 ServiceNow 能並肩合作的地方。

SAP S/4HANA 處理結構化的核心：交易、財務、採購與庫存，為管控與一致性而打造。ServiceNow 處理 SAP 從來不是設計來直接做的事：受理、核准、跨部門工作流程與例外處理。Clean Core 強化了這種切分。不適合放在 SAP 核心的工作流程邏輯，總得有個去處，務實的選擇是 SAP BTP 上的 side-by-side 擴充，或 ServiceNow。我的 Clean Core 指南說明了各種擴充選項。

連接是透過 BTP 上的 SAP Integration Suite、ServiceNow IntegrationHub 與開放 API 完成的，所以整個流程用起來像原生的，而不是外掛的。我認識一家全球客戶，用 SAP 做採購，用 ServiceNow 管理採購申請，這讓它不再需要客製入口網站；後來它又用同樣的架構處理供應商建檔。如果您還在跑 SAP Process Orchestration (PI/PO)，請規劃轉換：PI/PO 所運行的 SAP NetWeaver 7.5，主流維護將於 2027 年底結束，並可選購延伸維護到 2030 年。我的 SAP Cloud Integration 指南說明了目標平台。

1. 04ServiceNow跨團隊的受理、核准、例外與服務請求
2. 03整合透過開放 API，在 BTP 上的 SAP Integration Suite 與 ServiceNow IntegrationHub
3. 02擴充在 SAP BTP 上以 side-by-side 方式實作，放置不適合放在核心的邏輯
4. 01SAP S/4HANA 核心財務、採購、庫存與薪資，盡量貼近標準

依職能劃分的應用情境

人資。 SAP（或 SuccessFactors）保管員工主檔資料、角色、薪資與福利。ServiceNow 則協調跨 IT、人資、財務與資安的新進人員報到作業、存取權限配發、升遷核准與離職作業。

財務。 SAP 處理發票、保管帳本、執行結帳並產出法定報表。ServiceNow 負責工作流程層：

財務流程	SAP 的角色	ServiceNow 的角色
應付帳款	處理發票、比對採購單、管理付款	發票受理、例外轉派、SLA 追蹤
應收帳款	追蹤客戶發票與收款	轉派帳單爭議與信用額度凍結申請
財務結帳	期間結帳、公司間沖銷、報表	結帳檢查清單、任務指派、待辦項目警示
費用管理	記錄費用、落實政策、觸發報銷	轉送報告核准、標示例外
採購到付款	請購、採購單、收貨、供應商結算	受理表單、核准流程轉派、例外處理

採購。 SAP 管理供應商主檔資料、採購單、收貨與三方比對。ServiceNow 處理受理、供應商建檔查核、收貨問題與採購服務台。

設施與營運。 SAP 追蹤固定資產、維護成本與空間。ServiceNow 處理工作場所申請、維護工單、技術人員指派、存取申請與事件轉派。

AI 出現在越來越多現代化的討論中，而期待有時跑在成果前面。實務上，它處理邊緣案例、把重複性的工作自動化，並把人們漏掉的東西浮現出來。在 SAP 這一側，SAP 的 AI 助理 Joule，橫跨 S/4HANA、SuccessFactors、Ariba 與 SAP Build。在 ServiceNow 這一側，Now Assist 把生成式 AI 帶進它的 IT、人資與客戶服務工作流程。

工作通常這樣分工：

AI 應用情境	SAP 的角色	ServiceNow 的角色
發票比對	比對採購單、收貨與發票；標示異常	轉派例外，並優先處理高風險的不符項目
預測性維護	從設備資料分析使用與故障模式	開立維護工單並排定技術人員
現金流警示	依歷史資料預測現金部位	當流動性門檻被突破時，觸發警示與工作流程
虛擬代理	Joule 以自然語言回答橫跨各 SAP 應用程式的問題	虛擬代理與 Now Assist 處理申請並呼叫 SAP 後端
異常偵測	SAP BTP 上的模型或內嵌分析標出交易中的離群值	標出工作流程與核准中的異常，供稽核檢視
申請分類	在採購流程中建議類別	Predictive Intelligence 為案件分類，並轉派給正確的群組

我們合作過的一個 IT 團隊，在導入能重設密碼並擷取 SAP 資料的虛擬代理後，一個季度內，低價值支援工單減少了 30%。這個模式在 SAP 這一側同樣成立：當流程穩定、歷史資料乾淨、問題聚焦時，AI 的效果最好。即便如此，它是在支援團隊，而不是取代團隊。

現代化常常停滯，因為第一步感覺太大。我合作過一些客戶拖了好幾年，不是因為不夠緊迫，而是因為沒有人答得出「我們從哪裡開始？」。下面這個順序通常行得通：

1. 評估與整併。 在搬移平台之前，先把地基清乾淨。執行 SAP Readiness Check，衡量客製程式碼與相容性的規模。在移轉之前，而不是之後，清理主檔資料。決定哪些系統、報表與流程要留下來。決定部署路線（RISE with SAP、GROW with SAP 或地端），並規劃以 SAP Cloud ALM 作為您的生命週期工具，因為 SAP Solution Manager 的主流維護將於 2027 年底結束。做一次短期的技術探索衝刺，盤點什麼連到什麼，通常就能看出真正的風險藏在哪裡。
2. 從 ServiceNow 開始。 先建立受理、核准與工作流程。它們圍繞在 ERP 周圍，也引來最多抱怨。有一位客戶在 S/4HANA 移轉之前六個月，就用 ServiceNow 管理變更控管，把停機減少了 40%。這在您動 SAP 核心之前，先建立起紀律。
3. 用 Clean Core 搬移 SAP 核心。 以盡可能少的客製程式碼，把交易搬到 S/4HANA。貼近標準，能簡化升級、降低維護。把客製邏輯放在 side-by-side 擴充或 ServiceNow 裡，而不是核心裡。並且要問，未來五年 ERP 應該賦能什麼，而不只是把東西搬過去。
4. 優化與擴展。 在 SAP BTP 上加入分析與擴充，在適用之處加入 Joule，並在 ServiceNow 這一側加入 Now Assist、虛擬代理與低程式碼工作流程。

各階段可以重疊。讓 ServiceNow 的穩定化與 SAP 的就緒工作並行，可以縮短時程，又不必偷工減料。至於 S/4HANA 的部分，我的 ECC 移轉至 S/4HANA 指南說明了路徑與時程。

財務很早就會問成本，而這項決定即使從 IT 開始，通常最後也會落到財務長手上。

直接成本最先出現：基礎架構、託管、儲存與整合工具。授權與支援費用會維持不變，除非有人去整併，而許多團隊從來不去找沒用到或重疊的授權。在 RISE with SAP 上，請依 Full User Equivalent (FUE) 定價，為整個合約期間的使用者成長建立模型，因為第三年的訂閱費，很少等於第一年的報價。

間接成本比較難看見：緩慢的核准、錯失的 SLA、侵蝕對 IT 信任的整合失敗。它們不會出現在單一預算科目裡，卻會顯現在營運績效上。

要呈現投資報酬，就在改變任何東西之前先衡量：發票核准、新進人員報到與請購的週期時間；錯誤率；整合延遲。即使只有部分基準，也能讓報酬變成一個數字，而不只是一個故事。

這些陷阱在兩個平台上都會出現：

陷阱	SAP 上的失誤	ServiceNow 上的失誤
略過流程評估	沒有檢視流程缺口，就把舊系統的問題一併搬過去	沒有搞清楚真正的瓶頸，就部署申請表單
把工具當成萬靈丹	以為 S/4HANA 能修好沒人重新設計過的流程	以為自動化能修好沒效率的申請設計
忽略主檔資料	移轉重複或不一致的資料	依據不可靠的資料觸發核准
太早過度客製化	在核心流程穩定之前就建立擴充	在搞懂使用者行為之前就建立複雜的流程
沒有治理	把決定交給 IT 或供應商，卻沒有業務負責人	推出工作流程，卻沒有規則與 SLA 的負責人
忽略變革管理	對新的 SAP 流程訓練投入不足	沒有教使用者何時、如何使用新的申請類型

我記得有一位製造業客戶，以為問題出在他們的 ERP。真正的障礙，是一條橫跨五個團隊的人工核准路徑。等我們導入 ServiceNow 這一層，並把它連回 SAP，瓶頸就消失了。

現代化不必一次到位。有些系統留下，有些改變。隨著越來越多環境被連接起來，越來越少依賴變通做法，價值就會累積。

我們需要一次完成現代化嗎？

不需要。現代化分階段進行效果最好。許多組織先從 ServiceNow 工作流程著手，在動 SAP 核心之前先穩定營運，再依摩擦程度的順序處理其餘部分。

有一位客戶在 S/4HANA 部署之前，ServiceNow 的受理工作流程就已經上線。員工逐步適應，提高了採用度，也降低了抗拒。

在 S/4HANA 移轉中，舊有的客製化會怎麼樣？

要看它們的業務價值。SAP Readiness Check 能及早顯示客製程式碼的數量與相容性問題。大多數系統帶有的客製程式碼，比任何人以為的都多，而且其中很多已經不再使用。

Clean Core 傾向讓系統維持標準，擴充放在 SAP BTP 上，或把工作流程放在 ServiceNow。在 S/4HANA Cloud Public Edition 上，核心完全無法修改；在 Private Edition 與地端環境可以修改，但每一次修改都會增加升級的工作。留下確實有業務用途的，淘汰其餘的。

ERP 現代化需要多久？

從 ServiceNow 的受理工作流程開始，通常需要兩到三個月。移轉到 S/4HANA 依複雜度而定，常需 9 至 18 個月，對於客製化嚴重的大型多法人實體企業，則需要更久。

各階段不必一個接一個進行。讓 ServiceNow 的穩定化與 SAP 的就緒工作並行，可以縮短整體時程。

SAP 與 ServiceNow 現代化的務實投資報酬時程是多久？

大多數組織在三到六個月內會看到軟性的報酬：更短的週期時間、更少的人工交接、更好的可視性。具體的報酬，也就是可衡量的成本降低與效率提升，通常在 12 至 18 個月內出現，尤其是在兩個平台都開始貢獻之後。

開始之前，先追蹤週期時間、錯誤率與 SLA 達成情形。沒有基準，報酬就只是個故事，而不是數字。

怎麼知道 ERP 現代化已經遲了？

常見的訊號：支援工單增加、解決時間拉長，升級與修補一再延後，同一份資料有好幾個「唯一真實來源」，以及影子 IT 在填補 ERP 本該涵蓋的缺口。

一位執行 SAP ECC 的醫療照護客戶，單一季度就錯失了好幾項 SLA。問題不在努力不夠，而在技術債：多年來一層疊一層的小修補，事件登記的速度比任何人能分流處理的速度還快。

SAP 與 ServiceNow 可以與其他第三方系統整合嗎？

可以。SAP 使用 BTP 上的 SAP Integration Suite，以 API 為基礎連接外部系統。ServiceNow 提供 IntegrationHub，內建大多數企業平台的現成連接器，包括 Workday、Salesforce 與 Coupa。

從一開始就把整合當成一個工作流。太晚才界定範疇的介面，會在上線後造成最多摩擦，所以請在藍圖階段就開始整合設計。