香港Hypercare IT支援：ERP上線計劃

週一早上的上線問題，大多數不是ERP缺陷。它們是標籤打印機、掃描槍驅動、權限設定，以及找不到新界面的員工。香港Hypercare IT支援（上線強化支援）讓工程師在固定時間窗內駐場、收緊監控、開通直達的升級通道，並以書面交接轉入日常支援。

公司，以及一切改變的那個週末

設想一家香港的貿易與分銷公司，約九十名員工。公司從中國內地和東南亞的供應商進口消費品和輕工產品，賣給零售商、承包商和網店賣家。員工分在三個地方：銷售和財務辦公室佔據商業大廈的一層，倉庫在九龍東或葵涌的一幢工業大廈裡，還有幾位採購經常過關到供應商的工廠，靠手提電腦和手機辦公。

過去十一年，公司一直跑在一套老舊的會計軟件、一份悄悄變成“正式記錄”的庫存表格，以及散落在共享郵箱裡的訂單表單上。財務團隊每個月結帳要花將近一週，因為每個數字都得手工核對。財務總監終於批准了新的ERP，一個把訂單、庫存、採購和總帳放在一起的集成平台。實施夥伴已經簽約，切換定在一個週末：週五晚上凍結，通宵遷移數據，週日驗證，週一早上所有人登入新系統。

本文寫給發起這個項目的人，通常是財務總監，有時是營運總監。先說明一點：這是一個說明性的綜合場景，並非某個具體客戶。它取材於香港貿易分銷公司裡常見的一種處境，關於這家公司的所有數字都是為了便於計算而設定的假設。

公司只有一位內部IT，我們叫他IT主任。他能幹，熟悉每一台電腦和每一個密碼，平常一週已經忙到飽和。項目計劃裡，沒有人寫下週一誰來幫他。

這個遺漏就是本文的主題。ERP大體上會正常運轉。問題是，九十個人同一時刻學習新的工作方式時，圍繞ERP的一切由誰來照看。

ERP上線時，誰來修什麼？

先看一個簡單的事實：上線不是一件事，而是同一個幾天內發生的一長串小事，它們分屬不同的負責人。

ERP實施方負責什麼

實施夥伴負責ERP本身，包括配置、數據遷移、會計科目的準確性、流程、報表、關鍵用戶培訓，以及應用程式的缺陷。採購訂單稅額算錯、庫存移動沒有過帳，這是實施方的問題，好的夥伴會安排人手應對。

合同通常就是按這個範圍寫的，這也有道理。實施方不可能對公司的手提電腦、倉庫Wi-Fi或五年前買的標籤打印機負責。這些東西不是他們選的，他們看不到，上線期間他們的人也往往不在香港。

現場沒有人負責的事

再看一個真實的週一早上，倉庫和辦公室裡會冒出什麼。大致是這些：

倉庫的標籤打印機打出舊格式，因為驅動程式沒有為新標籤模板更新。
手持掃描槍連上了Wi-Fi，卻到不了新系統，因為某條防火牆規則或證書不在項目清單上。
財務有六個人能打開新系統，卻看不到總帳界面，因為角色權限是按一份過期的表格映射的。
銷售團隊的手提電腦習慣性打開舊的共用磁碟，文件繼續存錯地方。
一位用戶的單點登入提示不斷循環，是瀏覽器設定的問題，她連登入頁都進不去。
銀行接口或快遞對接原本悄悄運行，現在需要新的憑證，而持有人正在休假。
有人點了舊的快捷方式，什麼也沒找到，就告訴行政主管“系統掛了”。

這些沒有一個是ERP缺陷。但對於站在卡住的界面前的那個人來說，幾乎每一個都像ERP缺陷，所以它們匯成一股不加區分的投訴。財務總監看到的是“ERP掛了”，於是打電話給實施方，實施方得花時間證明不是它的問題。

造成損害的那道縫

這就是實施方範圍與現場其他一切之間的縫。這不是誰的錯，而是項目的組織方式（圍繞一個系統）與上線的體驗方式（圍繞一個想把活幹完的人）之間的錯位。

內部IT是唯一跨越兩邊的團隊，也是餘力最少的團隊。IT主任同時是項目的技術聯絡人、用戶卡住時第一個被找的人、必須保證其餘業務照常運轉的人，以及要向董事會解釋哪裡出了問題的人。我們這家公司的IT主任已經兩個月夜裡在寫切換清單。到週一上午十點，他已經被打斷了四十次。

如果這聽起來像你的項目，有用的問法不是“我們需不需要更多IT”，而是“在一個明確的時間窗內，誰實際站在現場、有權限動手解決，以及IT主任需要第二雙手時該找誰”。

什麼是Hypercare IT支援？

Hypercare是圍繞ERP上線、重大技術部署、新辦公室開業這類高風險事件的短期高強度支援服務。博迅在Hypercare IT支援服務頁面上把它描述為：在關鍵窗口期內，由經驗豐富的工程師實際駐場。下面用平實的話說明服務頁面所述的內容。

工程師在用戶身邊駐場

上線窗口期裡，工程師與員工並肩工作，在現場實時解決問題，防止它們升級成拖慢上線的事故。在我們的場景裡，就是標籤打印機和掃描槍的問題。有人就站在出問題的人旁邊，幾分鐘內解決，而不是等工單在隊列裡走一圈。

窗口期內收緊監控

Hypercare期間，監控閾值會收緊。服務頁面說明，具體是更快的輪詢間隔、更低的CPU和記憶體基線，以及對任何異常（而不只是嚴重異常）立即告警。道理很簡單：平時負載高了十分鐘才告警是合理的；上線期間，十分鐘的卡頓就是全部的故事，因為所有人都在同時試用新系統。

直達的升級通道

一條專屬的電話和聊天通道，把你的運營團隊直接接到博迅的高級工程師和管理層，不排隊，也沒有語音選單。服務頁面稱其在Hypercare窗口期內全天候可用。這很重要，因為棘手的問題往往出現在一天的邊緣：週日晚上驗證的時候，或者週一早上七點辦公室還沒坐滿的時候。

作戰室

博迅在上線期間設立虛擬或現場的作戰室，讓相關工程師和你的干係人在同一個溝通頻道裡，協調和決策都在一處完成。對一家有海外實施夥伴、財務總監、倉庫經理和IT主任的公司，一個統一的頻道比聽起來更有價值。它避免同一個故障被用三種說法報給三個不同的人。

每日簡報和有結構的收尾

每日Hypercare簡報涵蓋已提出、已解決和處理中的事故，項目發起人不用開口問，就能看到上線的健康狀況。Hypercare以正式交接結束：完整的事故日誌、經驗總結文件、已知問題登記表，並確認日常監控和升級通道已上線並經過測試。收尾部分最常被跳過，我們下面再回來談。

服務頁面沒有寫的內容

頁面沒有給出日費率、套餐價格或標準時長。它描述的是四個步驟：範圍界定與情況說明、工程師部署、Hypercare執行期、轉入日常運維，並說明窗口期、系統範圍、用戶數量和風險領域在第一步確定。本文沿用這個思路。下面給出的人數或時長，都是這家說明性公司的假設，不是博迅公佈的數字。

需要幾位工程師、多少天、哪些班次？

規模估算是Hypercare決策最容易做錯的地方：不是出於恐懼買多了，就是為了壓縮預算買少了。更好的辦法是從需求的形狀出發。

從人和地點出發

需求不是平均分佈的。它集中在兩處：人們第一次使用新系統的地方，以及硬件接觸新系統的地方。對我們的公司來說，就是倉庫現場（掃描槍、標籤打印機、共用終端，用戶不習慣坐辦公桌），以及財務辦公室（權限和總帳，用戶非常習慣坐辦公桌，任何錯誤都逃不過他們的眼睛）。

公司約九十人，假設其中六十人每天使用系統，三十人偶爾使用。這些是我們在示例裡沿用的假設。

一個明確標註為假設的計算示例

下面的人手安排是這家說明性公司的，不是博迅的規則。它展示了一個雙地點、九十人的公司，計劃可能是什麼樣子。

倉庫：前三個工作日派一名工程師，因為這裡設備最多、對停擺最不能容忍。之後每天短時間上門。
辦公室：前三個工作日派一名工程師，覆蓋財務、銷售和共用設備。之後工程師在辦公室和倉庫之間分配時間。
升級通道與監控：整個窗口期都啓用，讓現場工程師遇到異常情況可以隨時拉高級工程師支援。
IT主任：受到保護。他依然是公司系統的負責人，不用去管現場的雜事。工程師接手隊列，他來做決定。

也就是前三個工作日兩名工程師，之後一名，全程有高級工程師遠程支援。這是一個討論的起點，不是建議。你自己的數字取決於有幾個地點、第一天有多少用戶的工作方式變了、有多少實體設備依賴新系統，以及你已有多少遠程能力。

窗口期應該多長？

有兩件事決定長度。第一是適應曲線：支援需求在第一天最高，隨著大家熟悉界面而下降。第二是第一次月結，這是ERP真正受到檢驗的時刻。窗口期如果在第一次月結之前結束，財務團隊就會在最需要幫助的時候無人支援。

在這個場景裡，合理的計劃是：前三個工作日重點駐場，頭兩週其餘時間輕度駐場，監控和升級通道一直開到第一次月結完成。這是對這家虛構公司的判斷。對你的公司，範圍界定這一步的意義就是用證據而不是猜測來做這個決定。

哪些班次？

班次要匹配人們實際工作的時間。早上七點開始裝貨的倉庫，需要工程師在那之前到場，而不是九點。月結當晚要加班的財務團隊，晚上需要一位聯繫得上的工程師。工程師不在現場的時段，由升級通道兜底。

香港還多一個考慮：雙語覆蓋。倉庫主管更習慣用粵語，實施方的顧問用英語工作，內地供應商聯繫人用普通話。能在這些語言之間順暢切換的工程師，節省的時間很難量化，卻很容易感受到。

最初72小時是什麼樣子？

下面是我們場景的逐時計劃。細節屬於這家說明性公司，但工作的先後順序對週末切換來說很典型。

週五晚上到週六：還沒人登入之前

工程師在凍結前到場，如果這個階段是遠程工作，則接入作戰室頻道。他們聽取切換計劃和在範圍內的系統清單的說明。監控閾值收緊。升級通道通過一次測試電話確認，作戰室頻道建立，實施方、財務總監、倉庫經理和IT主任都在裡面。

第一項有用的工作，是把所有接觸新系統的東西做一次實物盤點：每把掃描槍、每台標籤打印機、每個共用終端、每台分配給關鍵用戶的手提電腦。這項工作枯燥，卻恰恰是項目計劃以為有人做過的那一項。

週六：遷移之夜與第一輪測試

實施方遷移數據的時候，現場工程師對著測試環境逐台設備檢查：每把掃描槍能否連上系統，每台打印機能否打出新標籤，每位關鍵用戶能否登入。任何失敗都記下、修復、複測。週六連不上的掃描槍只是不方便；同一把掃描槍週一早上七點在碼頭失敗，旁邊還有一輛貨車在等，就是一起事故。

週日：有安全網的驗證

關鍵用戶驗證自己的界面，權限問題就是在這時暴露出來的：財務團隊看不到總帳界面，倉庫主管無法審批庫存調撥。每一項都登記在作戰室裡，分配給對的負責人（角色映射歸實施方，設備和訪問歸工程師），在當天結束前關閉。

週日晚上，工程師和項目發起人開一次簡短的就緒評審，列出哪些已就緒、哪些已知未解決、每個未解決項的臨時辦法。原則是：不要有意外。

週一早上七點到十點：高峯

計劃經受檢驗的時刻到了。工程師在第一班之前已經在現場。倉庫的工程師站在收貨碼頭旁，辦公室的工程師在財務區，兩人都在作戰室頻道裡。

這個時段最常見的求助，就是前面列的那些：找不到界面、設備掉線、權限不對。它們當場解決。真正屬於ERP缺陷的，會連同已收集好的證據轉給實施方，讓實施方把時間花在缺陷上，而不是花在證明這不是網絡故障上。

週一中午到週二：長尾

第一個早上的高峯過去，出現了另一種模式：憑直覺熬過早上的人，現在碰到第二層問題。導不出來的報表；掃描件掛在錯誤的記錄上；快遞對接需要新憑證。當天結束時的每日簡報列出已提出、已解決和仍未解決的事項。財務總監讀到的是未解決問題的數量在下降，而不是從焦慮的同事那裡聽來的。

到週二晚上，輪廓通常已經清楚。如果計劃對了，需求已經在下降，工程師救火少了、教學多了，未解決的項目是一份簡短而且清楚的清單。

實施方支援、內部IT單打獨鬥，還是Hypercare？

覆蓋一次上線，現實中有三種方式。下面用發起人最關心的幾個問題來比較：誰修什麼、持續多久、結束時還剩下什麼。

ERP實施方的上線後支援

誰修什麼：ERP應用程式，包括配置、數據缺陷、流程和報表。設備、網絡、打印機，以及應用之外的用戶訪問，通常不在合同範圍內。
持續多久：合同怎麼寫就多久，往往是上線後的一段約定時間，而且通常是遠程交付，現場時間有限。
結束時剩下什麼：一個穩定的應用，以及一份未結缺陷清單。實施方的記錄只覆蓋ERP，別的什麼都沒有。
最適合：應用問題。它是這類問題的正確負責人，無論如何都應該讓它保持在溝通鏈裡。

只靠內部IT

誰修什麼：理論上是一切。實際上是IT主任先夠得著的東西，按嗓門最大的人的順序。
持續多久：要多久就多久，也就是IT主任的夜晚和週末。
結束時剩下什麼：一位非常疲憊的IT主任，沒有獨立的事件記錄，而且如果他辭職，知識會跟著他走。
最適合：用戶只有寥寥幾人的小型切換，IT主任確實有餘力，而且上線不涉及太多實體設備。

Hypercare服務

誰修什麼：現場，也就是設備、打印機、掃描槍、訪問、連接、用戶指引和監控，對應用缺陷則有直通實施方的清晰渠道。
持續多久：一個明確的窗口期，在範圍界定時約定，有明確的終點。
結束時剩下什麼：正式的交接包，包括事故日誌、已知問題登記表和經驗總結文件，並確認日常監控和升級通道運作正常。
最適合：同時涉及很多用戶和很多設備的上線，而內部IT已經滿負荷。

這三者與其說是互相替代，不如說是三個層次。實施方管應用，內部IT管公司的系統，Hypercare是臨時增加的人手，讓兩邊在負荷最高的那幾周都能把本職做好。

Hypercare什麼時候結束？

沒有終點的支援窗口不是Hypercare，而是一份沒計劃好的外判安排，通常比有計劃的更貴。在上線之前就約定好退出標準，才能讓這次合作保持簡短而誠實。

值得寫下來的退出標準

標準因公司而異，但一份好的清單大致如下：

沒有超過約定嚴重級別的未結事故，也沒有阻止業務流程運轉的未解決問題。
每日事故量已連續多個工作日低於約定水平。
第一次月結，或同等意義上的第一個完整業務週期，已經完成，沒有現場級的阻礙。
日常監控已上線，告警閾值回到標準值，並且一次測試告警已送達正確的人。
日常運維的升級通道已經端到端測試過，而不是只寫在文件裡。
發起人讀過最終簡報，並認可剩餘事項可以接受。

這份清單應當書面約定，這樣決定收尾就成了對照標準的檢查，而不是一場談判。

交接包

服務頁面列出了轉入日常運維時包含的內容，值得當作檢查清單來用。

事故日誌：每一個提出的問題、如何解決、花了多長時間。一年後，它會解釋為什麼某個設定是現在這個樣子。
已知問題登記表：仍未解決的事項，誰負責，臨時辦法是什麼。
經驗總結文件：上線暴露了環境、培訓和流程的哪些問題，趁記憶新鮮時寫下來。
日常運維支援的確認：監控和升級通道已上線並經過測試，這樣工程師離開的第二天，有人知道該打給誰。

交接包的意義在於，知識屬於公司。如果IT主任半年後辭職，上線期間發生了什麼，並不只存在於他的腦子裡。

Hypercare的費用，與延誤一次月結相比如何？

我們不報價，因為博迅的Hypercare頁面沒有公佈價格，而價格取決於範圍。你可以通過範圍界定的溝通獲得報價；博迅的價格頁面也展示了它在公佈價格的服務上是怎樣列出費率的。這裡更有用的，是如何權衡這筆費用。

用你自己的數字，和糟糕的第一個月的代價比一比。問五個問題：

如果倉庫半天發不了貨，滑期的訂單價值是多少？
如果第一次月結要花兩週而不是一週，財務時間的成本是多少，又有哪些決策在等這些數字？
如果財務總監頭一週變成項目的投訴熱線，而不是在管財務，有什麼事沒人做？
如果IT主任在上線後過勞或離職，替換他並找回他所掌握的知識要多少成本？
如果客戶在第一週收到遲到或錯誤的貨，對客戶關係的代價是什麼？

你不會有精確的答案，也不需要。只要其中任何一項的代價，看起來比一次短期、明確範圍的合作更大，決定就已經清楚了。如果一項也沒有，你大概不需要Hypercare，更輕的安排可能就夠了。

第二種可能性值得認真對待。一個只有十五位用戶、沒有實體設備、內部IT人手充足的上線，也許不需要駐場工程師。Hypercare適用於負荷高、容錯空間小的情形。

Hypercare是一次衝刺，之後現場靠什麼運轉？

交接裡最重要的一句話，不是關於工程師離開，而是關於他們離開後的第二天有什麼在位。

Hypercare有意設計成臨時的，它在幾周內抬高了支援水平。之後，現場需要一個穩定的模式，和公司實際使用的IT量相匹配，而這次上線會為你提供有力的證據：事故日誌顯示哪些問題反覆出現、哪個地點來電最多、需求落在哪些時段。

常見的去向有三種：

定期加按需的模式。對IT需求不大的公司，定期上門加遠程協助也許就夠了。另一篇文章香港駐場IT支援的幾種模式比較了駐場、定期和派單這幾種做法。
一位專屬工程師。如果事故日誌顯示，倉庫加辦公室的工作量足以讓一個人忙起來，博迅的全職駐場IT支援提供一位指名的工程師，休假時有替補，並有博迅整個團隊做後盾。
IT主任身後的服務台。如果壓力出現在正常時間之外，24×7服務台以普通話、粵語和英語應答；博迅公佈的數字是每年處理約15,000起事件，90%的來電在40秒內接通。

它們並不互斥，而是可以合併成管理型IT外判服務下的一個安排，而大多數走過一次Hypercare窗口的公司最終都會走到這裡，因為他們剛剛發現，自家那位唯一的IT做了多少看不見的工作。博迅創立於2007年，總部位於新加坡，自2016年起在香港觀塘設有常駐工程辦公室。

常見問題

Hypercare應該持續多久？

沒有公佈的標準，博迅的服務頁面也沒有給出，因為窗口期是在範圍界定時根據你的上線計劃確定的。通常有兩件事決定長度：頭幾天之後需求下降得多快，以及第一個完整業務週期（例如第一次月結）何時完成。在我們的說明性公司裡，這意味著前三個工作日重點駐場，兩週內其餘時間輕度駐場，監控和升級通道一直開到第一次月結完成。請在上線前就以書面約定退出標準。

Hypercare只適用於ERP項目嗎？

不是。博迅把Hypercare描述為適合ERP上線、重大技術部署、新辦公室開業和高風險業務事件，服務頁面列出的場景包括ERP、Microsoft 365、辦公室開業和雲遷移。共同點是：短時間內很多人和系統同時變化，而且失敗的代價很高。

ERP供應商或實施方會提供這個嗎？

現場層面通常不會。實施方負責應用：配置、數據、流程和缺陷。設備、打印機、掃描槍、網絡和應用之外的訪問，一般不在這個範圍內，你可以在自己的合同裡核實。有些實施方可以推薦或協調一家夥伴來做這件事。實際的做法是，書面詢問實施方，他們的上線後支援具體包括什麼、不包括什麼。

100位用戶需要幾位工程師？

這更多取決於地點和設備，而不是人數。一百人在同一個坐辦公桌的辦公室，與一百人分佈在辦公室和一個滿是掃描槍和打印機的倉庫，是兩種不同的問題。在我們說明性的九十人公司裡，計劃是前三個工作日兩名工程師，之後一名，全程有高級工程師遠程支援。這是示例的假設，不是規則。人數應當在範圍界定這一步，依據你的用戶數、地點和風險領域來定。