用ChatGPT起草ERP上線UAT腳本與切換手冊

簡而言之： 用你自己的話把每一條業務流程描述給ChatGPT，讓它產出帶前置條件、步驟、預期結果、以及大家總會漏掉的例外情境的UAT測試腳本；再讓它把你的切換順序變成一份帶負責角色、時間、Go/No-Go決策點與回復觸發條件的切換手冊。它能在幾小時內起草完這些文件。它無法承擔那個決定，也不可能在切換那個週日的早上六點站在現場。

ERP上線前六週，幾乎每一家中型公司的文件狀態都一樣：有一份專案計畫，有一份導入夥伴的標準範本，還有一個共用磁碟，裡面躺著三份寫了一半的測試腳本——出自某個週二稍微清閒一點的人之手。顧問們在做設定。真正知道訂單怎麼流轉的業務使用者在忙他們的本職工作。而剛剛有人問：切換手冊誰來寫？

這項工作在智力上並不難。它量大、枯燥，而且恰好需要那些沒有時間的人。這個組合正是它總是遲到、又總是比應有的更單薄的原因——也正是語言模型擅長的那類起草工作。

以下內容有一個前提：判斷權仍在你手上。模型寫出文件的第一版；由你的人判斷它對不對，也由你的人扛過那個週末。

上線文件為什麼總是遲到、又總是單薄

四個原因，把它們叫出名字，有助於你據此安排。

它和設定搶時間。 系統沒設定完就無法完整測試，於是寫測試腳本顯得為時過早——而等設定做完，上線日期已經很近，什麼都變成緊急的了。

它需要的是業務知識，不是系統知識。 顧問懂那個模組；但只有你們的信用控管人員知道，客戶在下單過程中超出授信額度時到底會發生什麼。把這些抽取成書面步驟要佔用他們的時間，而那是專案裡最稀缺的資源。

例外情境被跳過了。 所有人都會寫正常路徑。沒有人會寫部分出貨、跨已關帳期的折讓單、或者一個客戶同時掛著兩份有效價格協議的測試——而上線真正垮掉的地方恰恰在這裡。

切換手冊被當成了清單，而不是一條序列。 一份任務列表不是切換計畫。切換計畫有順序、有相依、有時間、有具名的負責角色，還有明確的「到這裡判斷要不要繼續」的節點。

ChatGPT能從一段流程描述裡起草出什麼

輸入不是你的ERP系統，而是你對「這門生意是怎麼運轉的」的描述——用白話，由真正知道的人來寫。

怎樣才能得到值得跑的UAT腳本？

把一條流程從頭到尾描述一遍——它從哪裡開始、誰會經手、系統應該做什麼、有哪些例外。然後要求它按固定結構產出測試腳本：測試編號、流程領域、前置條件、涉及角色、編號步驟、預期結果，以及一個通過/失敗欄位。

有兩條指令，決定了你拿到的是籠統的腳本還是有用的腳本。

明確要求例外與邊界情境。 「產出一個第一次做導入的人會忘掉的失敗路徑」，會給你部分出貨、倒填日期的發票、稅碼例外、審批額度臨界值這些情境。其中一些你會因為不適用而丟掉；留下來的那些，正是本來要等到上線第一週才會浮出水面的問題。

要求它列出自己做過的假設。 一個悄悄把空白填上的模型是負債。而一個在結尾寫著「我假設啟用了三單勾稽，並且信用額度是阻斷而非僅提示」的模型，交給你的是一份複核清單——而那些假設，往往正是你們專案本該早就回答的問題。

不要把資料放進去。描述「一張訂單有客戶、價格協議與交貨日期」就夠了；不要把真實的客戶主檔貼進去。測試腳本需要的是形狀，不是紀錄。

怎樣把切換計畫變成一份手冊？

把你打算走的順序在高層次上給它——最後一次備份、在舊系統凍結交易、匯出餘額、載入主檔、載入未結項目、對帳、驗證、開放新系統——再加上你手上有哪些角色，以及你有多長的視窗。

要求它以編號清單的形式產出一份切換手冊：步驟、負責角色、開始時間、時長、相依、驗證檢查、回復觸發條件。最後兩個欄位，恰恰是手寫手冊裡最常漏掉的，也是凌晨四點最要緊的。

然後問那個更難的問題：「在這條序列裡，我們還能乾淨地中止的最後一個點在哪裡？」那就是你的Go/No-Go決策點；讓模型先提一個，你的專案經理就有了一個具體的東西可以去反駁，而不是面對一張白紙。同樣是「先讓模型起草結構、再由人修正」的模式，在產生SOP與到職文件那篇裡也成立，而「修正」這一步正是讓兩者都安全的原因。

一個實際例子——一條訂單到收款流程變成腳本和一個切換時段

一家350人的經銷商要在一個三天的週末完成新ERP切換。財務系統負責人用大約600字描述了訂單到收款：從EDI與電子郵件接單、信用檢查、從兩個倉庫分配庫存、允許部分出貨、出貨即開發票、帳期按客戶群不同、短交時開折讓單。

從這段描述出發，一次產生大約產出25條UAT腳本，涵蓋標準訂單流程、超授信、部分出貨與欠交、價格協議優先順序，以及折讓單路徑——同時模型列出了它不得不做的五條假設。其中三條被證明是錯的，這是發現而不是失敗：修正它花了二十分鐘，而且它暴露出專案在分配規則的定義上確實存在缺口。

業務使用者的複核才是真正價值出現的地方。讀25條起草好的腳本並修改，所花的時間只是從零開始寫的一小部分；而「讀」是一個忙碌的人在下午五點真的會去做的動作。兩條腳本因不適用被刪掉，六條被實質重寫，還新增了四條——那些只有信用控管人員知道的情況。

切換時段用同樣的方式起草。這條序列變成了橫跨週末的40個編號步驟，每一步都有負責角色、時長、驗證檢查與回復觸發條件——外加一個建議的Go/No-Go決策點，訂在週六14:00，在餘額載入並對平之後、第一筆實際交易之前。專案經理把這個點往前挪了兩個小時，理由是模型不可能知道的：財務總監週日上午的班機。

這項工作產出的不是一份完成的計畫，而是一份在一天之內做出來的、完整的初稿，讓真正要緊的那些人有東西可以反應——而這與「從無到有把它做出來」是根本不同的兩個問題。

AI起草的上線文件 vs 導入夥伴範本 vs 從零開始

貼合你們真實業務的程度 — AI起草勝出。夥伴範本描述的是一條通用的訂單到收款流程；而你寫的那段描述，描述的是你們自己的。
例外情境的涵蓋 — AI起草勝出，前提是你明確要求它。這是實務中最大的一項收益。
拿到初稿的速度 — AI起草明顯勝出。是幾小時而不是幾週，而那幾週是由別人的會議構成的。
經過驗證的結構與完整性 — 夥伴範本勝出。它把別的導入專案上出過的問題固化了下來，而那是你和模型都不具備的知識。
出錯時誰負責 — 夥伴範本勝出。背後有一個簽了合約的人，而這一點在上線之前的分量，比多數團隊願意承認的更重。
組織自身的學習 — 從零開始在一個很窄的意義上勝出：寫腳本會逼人去想清楚。這個好處是真實的，但它不值六週。

最強的組合是顯而易見的那個：用導入夥伴的範本做骨架、用AI起草把你們的流程與例外填進去、再由你們的人來修正。這裡沒有任何一句話是在建議甩掉導入夥伴。

AI在一次上線裡做不到的事

三件，而它們恰好決定了那個週末順不順利。

它無法承擔Go/No-Go的決定。 那個判斷要權衡資料品質、業務風險、人手、對客戶的承諾，以及所有人有多累。它屬於一位有權限的具名人士，而且應當依據事先約定、在沒人被壓力裹挾時寫下來的標準來做。

它不了解你們的資料。 我見過的每一次嚴重的上線問題，追根究柢都回到資料上——重複客戶、對不平的未結項目、一個被拿來存放它從未被設計承載的東西的舊欄位。這些模型一個都看不見，而它會心安理得地寫出一條假設你的主檔是乾淨的測試腳本。

它不可能在現場。 必須有人在凌晨兩點載入失敗時在場、在週一早上使用者開不出第一張發票時在場、在對帳差了一個沒人解釋得清的金額時在場。那是在關鍵視窗期內嵌入式的、動手的在場，也正是Hypercare上線支援存在的意義——工程師在上線期間以及其後那幾週脆弱期駐點。

把這件事做對——業務流程保密、API金鑰，以及什麼時候該讓IT介入

在你開始把流程描述往聊天視窗裡貼之前，有三點實務問題。

你實際上揭露了什麼。 一段詳細的流程描述在商業上是有分量的：價格結構、審批門檻、客戶帳期、你們控制薄弱的地方。請以結構化的方式描述流程，把真實資料、客戶名稱與具體數字留在外面。使用商業版或企業版，並閱讀你實際所在層級的資料處理與訓練條款，而不是想當然——消費者層級通常不同，條款也會變。

產出物放在哪裡。 UAT腳本與切換手冊是專案紀錄——它們應當放在有版本控制、有主人的專案庫裡，而不是聊天紀錄裡，也不是某位顧問的個人雲端硬碟裡。下一期、下一個法人主體的推廣，以及那場追問「這次移轉是怎麼受控的」的稽核，你都還會用到它們。

模型寫完之後歸誰管。 起草是便宜的那部分。和業務使用者逐條複核腳本、對帳、給週末排班、並消化上線後頭兩週的問題，才是真正的工作，而這正是我們的AI+支援服務和託管IT支援針對這類專案所建構的。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室——跨多個法人主體的亞太推廣，正是我們的常規領域。

常見問題

把我們的業務流程描述給AI工具安全嗎？

取決於你怎麼描述、用的是哪個層級。結構化的描述——「訂單可以部分出貨，出貨時開發票」——比貼進價格表、客戶帳期或真實紀錄的風險要低得多。請使用商業版或企業版、核對它目前的資料處理條款，並把真實資料留在外面。如果合約或法規不允許，同樣的方法在自架模型上照樣成立。

我們的導入夥伴不是本來就該提供這些嗎？

他們會提供範本與方法論，這兩樣你都該用。夥伴很少提供的，是你們業務裡那些具體的例外情境，因為那些長在你們員工身上。AI起草是快速補上這塊的辦法。如果你的夥伴已經在產出完整、貼合業務的UAT腳本，那你有一個不錯的夥伴，這件事對你就沒那麼急。

怎麼驗證AI寫的測試腳本是完整的？

你無法只看腳本就驗證完整性——你要對照流程來驗證。讓每條流程的業務負責人讀一遍腳本、說出缺了什麼；讓模型列出它做過的假設；再把涵蓋範圍和你們上一季實際發生過的交易類型做對照。如果某個交易類型在業務裡發生過、卻沒有任何腳本涵蓋它，那就是缺口。

一份回復計畫裡該有什麼？

最後一個已知良好狀態、怎麼回到它、誰來決定、需要多久，以及「過了哪個點回復就不再現實」。最後這一項是團隊最不願意寫下來的，也是最重要的——在第一批實際交易過帳之後，「回復」通常意味著「跑兩次對帳」，而不是「復原」。

Go/No-Go歸誰？

一位具名的人，通常是專案發起人或指導委員會主席，依據事先約定的標準來判斷。請在週末之前幾週就寫好這些標準——那時沒人疲憊，也還沒為待命人手花過錢。在切換週六的14:00於會議室裡現場決定標準，正是專案在一個還沒準備好的系統上上線的方式。

分階段推廣到其他法人主體時也能用同一套做法嗎？

能，而這正是它第二次產生回報的地方。第一個主體的腳本與手冊一旦存在，把它們改造給下一個國家或法人主體就是小得多的工作——讓模型按你描述的差異做調整，再由當地團隊複核。真正要緊的差異，通常是稅務、法定報表與審批層級。

從哪裡開始

挑你們量最大的那條流程，用500字描述它，要求產出包含例外情境與假設清單的UAT腳本。把產出交給這條流程的業務負責人，看他劃掉了什麼——那個反應比初稿本身更有價值，它會告訴你：你們的上線風險裡有多少是文件問題，有多少是資料問題。如果結論是「文件還扛得住，但沒人能扛那個週末和隨後的兩週」，那是一場值得早點開始的人力對話——聯絡我們。