採購 COBOL 現代化服務，和買任何其他軟體工作都不一樣。要動的那套系統已經跑了三四十年，公司裡現在沒有一個人完全弄得懂它，而做壞了的代價不是錯過幾個迭代，是法遵申報出問題。與此同時，擺在你桌上的幾份提案承諾的結果一模一樣，報價卻差了好幾倍。

這篇文章講清楚一份認真的合作究竟包含什麼，幾類供應商之間的差別在哪裡，以及哪些問題能把建立在證據上的報價，和建立在樂觀上的報價分開。它假設你就是事後必須為這個決定提出說明的那個人。

該看什麼： 一份可信的 COBOL 現代化提案包含現況盤點、目標架構設計、資料遷移、程式碼轉換或重新託管、以比對為核心的測試計畫、平行運行、切換規劃以及知識移轉。只替程式碼轉換標了價的報價，不是一份專案計畫，它只是其中最便宜的四分之一。

COBOL 現代化服務實際包含什麼

找三家供應商要提案，你會拿到三種不同的範圍定義。在比價之前先把清單對齊，是這個階段最有用的一件事，因為漏掉一半工作的報價，在摘要頁上永遠比較好看。

現況盤點與分析 排在最前面。供應商會剖析整套資產，畫出相依關係與資料血緣圖，找出不再執行的程式碼，並交出程式、複製簿、作業流與資料庫物件的清單。這個階段還應當把推高成本的東西點出來：組合語言模組、異常的交易處理方式、變體記錄結構，以及那些編譯器容忍了幾十年的寫法。

目標架構 緊接在後。總得有人決定這套系統將來是什麼：一份被重新託管的 COBOL 工作負載、一份轉換到現代語言的程式碼庫、一組服務，或者是分階段推進的某種組合。這個決定應當落在轉換動工之前，而且要把推導過程寫下來讓人看得見，而不是丟下一句結論。

資料遷移 涵蓋結構設計、擷取、轉換與對帳。大型主機的資料格式承載著關聯式結構無法直接表達的意義，所以這部分工作是分析性的，而不是機械性的。

程式碼轉換或重新託管 是所有人都盯著的部分，而它在總工作量裡通常只佔少數。自動化在這裡能做什麼、不能做什麼，我們談大型主機遷移工具 的那篇文章寫過。

買方最常砍掉的環節

測試與比對 才是錢真正花掉的地方。像樣的專案會搭一套框架，用同樣的輸入分別跑舊系統與新系統，再逐欄位比對輸出，然後把每一處差異都推到要嘛修掉、要嘛被正式接受為止。這本身就是一個軟體專案，也應該當作軟體專案來報價。

平行運行與切換 指的是在一段約定的期間內，用真實的生產量同時運行兩套系統，然後帶著演練過的回復方案完成切換。那些為了省時間跳過這一步的專案，後來會以不太光彩的方式出現在案例裡。

知識移轉與支援 為合作收尾。供應商撤走之後，你自己的團隊必須能運行它、能修改它。如果這不是一項帶驗收標準的明確交付項目，你買到的就不是現代化，你買到的是依賴。

三類供應商，各自擅長什麼

這個市場分成三類，長處確實不同，而選誰更多取決於你的資產本身，而不是任何排行榜。

工具廠商與其合作夥伴 用自動轉換或重新託管平台打頭陣。他們的技術通常相當成熟，轉換吞吐量也確實可觀。要留心的是利益的方向：他們的商業利益在於把自家產品承擔的比例做大，而這未必等於替你造出一份維護起來舒服的程式碼庫。此外，他們會把你的正式環境資產綁在自家執行環境上，這是一份值得標價的依賴。

全球系統整合商 帶來的是規模、專案治理，以及組織一支跨年度大團隊的能力。如果你的資產橫跨多個事業單位、達到數百萬行，這份供給能力是真的管用，而能提供它的人不多。代價是成本結構，以及寫提案的人和真正動手的人之間的距離。請具體問清楚誰在團隊裡、他們坐在哪裡、有過什麼經歷。

專業工程公司 規模小，從頭到尾都是資深的人在做，而且因為沒有產品要賣，通常對工具保持中立。他們適合數十萬行量級的資產、分階段推進的專案，以及難處在業務邏輯而不在體量的情形。他們組不出一個兩百人規模的專案，而且應當直說。

不存在放諸四海皆準的答案，只存在對某一套資產而言正確的答案。凡是聲稱自家模式適合一切情形的供應商，都在告訴你一些關於他們怎麼賣東西的有用資訊。

能問出虛實的問題

採購問卷很少能問出真正要緊的東西，下面這些可以。

「把我們最難的那個模組轉出來，讓我們看看結果。」 挑那個人人繞著走的程式，最好是會呼叫組合語言、又帶多層變體記錄的那一支。要看產生出來的程式碼本身，而不是一份摘要。對自家做法有把握的供應商，會在一筆金額固定、數目不大的盤點費用裡做這件事。不情願本身就是答案。

「十進位運算和排序順序你們怎麼處理？」 壓縮十進位欄位和大型主機的排序規則，都會製造出只在財務結果與報表排序裡才顯形的差異。回答應當是具體的、技術性的。在這裡含糊其辭，預示著一段難熬的使用者驗收期。

「你們的測試範圍到底包含什麼，比對框架由誰來寫？」 你要找的是一項有名字的交付項目、一份工作量估算，以及關於誰來提供接近正式環境資料的明確說法。如果測試被描述成開發工作量的某個百分比，那這家供應商是在猜。

「解釋不了的差異，你們怎麼辦？」 每個專案都會碰到輸出對不上、誰也說不清緣由的情況。好的供應商會描述一套帶業務方簽核的分流程序。說這種事不會發生的，要嘛沒把一個專案做到底，要嘛沒在說實話。

「最後產出的原始碼歸誰，我們能不能走人？」 答案應當是一切完全歸你所有，繼續運行不需要任何執行環境授權。如果答案裡有任何一部分牽涉到對某個專有層的持續付費，請弄清楚一旦你停付，正式系統會發生什麼。

「講一個做壞了的專案，以及你們後來改了什麼。」 凡是做過幾個以上這類專案的機構，都有這麼一段。這個回答會告訴你，坐在對面的是工程師還是業務職能。

COBOL 現代化服務如何定價

定價模式有好幾種，每一種分攤風險的方式都不同。理解這種分攤，比看清封面上的數字更重要。

按實際投入計費，對確實存在未知的工作來說是最誠實的模式，對董事會來說則是最不舒服的模式。它適合現況盤點，而現況盤點幾乎總應當單獨採購、並且放在最前面，正是為了讓後面的部分能按證據而不是按假設來定價。

按模組或按每千行的固定價，在轉換工作裡很常見，並且在盤點已經弄清模組裡裝了什麼之後是合理的。請仔細讀那些除外條款。這類價格通常假定程式碼落在一個約定的複雜度區間內，超出這個區間的會被單獨重新報價，波動就藏在那裡。

按成果定價，也就是把付款綁在已被接受的功能等價上，在動機上對得很齊，但它要求驗收標準精確到能夠據以裁斷。把這些標準認真定義清楚，值得花那份力氣。

對於盤點還沒跑就給出整個專案確定固定總價的公司，請保持懷疑。那不是自信的表現。它要嘛加了足以覆蓋最壞情況的餘裕，於是你在為一份可能不會發生的風險付錢；要嘛定得樂觀，等難啃的模組浮出水面時以變更申請的形式回來。哪一種都不划算。

至於折扣，這個市場並不那樣運轉。有意義的減價來自收窄範圍、把專案分階段讓後面的階段吃到前面階段學到的東西，或者下架那些盤點證明已經沒人使用的程式碼。範圍一點沒變卻大幅降價的供應商，等於親口告訴你第一個數字是隨口報的。預算究竟花到哪裡去了，我們的 COBOL 遷移成本與時程指南 做了拆解。

值得堅持寫進合約的條款

有那麼幾條條款，比堆多少治理機制都更能保住結果。

堅持對所有交付的原始碼、資料結構、指令稿與測試資產擁有沒有附加限制的所有權，比對框架也包含在內。那套框架是你今後好幾年還會用到的資產。

把驗收定義為在約定資料集上示範出功能等價，而不是交付程式碼。「轉換完成了」和「輸出對上了」之間的距離，就是這個專案的全部。

要求一個分階段、帶真實退出點的結構。一個拆成盤點、試辦、分批轉換與切換的專案，允許你在任何一個階段之後停下來，手裡還留著有價值的東西。一份鐵板一塊的合約做不到這一點。

把關鍵人員的名字寫進合約，並加入關於換人的條款。來投標的團隊和真正到場的團隊之間的落差，是這個市場裡最常見的抱怨。

最後，把知識移轉做成一項有自己驗收標準的交付項目，以你的團隊獨立完成一次真實變更作為憑據。否則它就會變成最後一週發下來的一疊投影片。

找工程師談，而不是找經銷商

Mecanik 以獨立工程公司的身分承接 COBOL 現代化 與 COBOL 遷移 專案。我們不轉售任何轉換平台，所以我們在工具上的建議反映的是你的程式碼庫需要什麼，而不是我們拿了誰的授權。

我們從現況盤點和一次針對你最難那個模組的付費試辦開始，因為這樣得出的估算扎根於你自己的程式碼，而不是一個業界平均值。從那裡出發，我們可以轉換、可以重新託管，也可以告訴你眼下兩者都不成立，而這偶爾正是正確答案。各階段更細的內容寫在我們的 COBOL 遷移服務 頁面上，而排在這一切之前的重寫、重構還是換平台的取捨，我們在大型主機現代化策略 指南裡談過。

告訴我們你的資產大概多大、是什麼在逼著這個時間點，我們會告訴你一個實際的專案大致長什麼樣。

延伸閱讀： COBOL 到 Java 遷移 - 英國企業指南 、COBOL 到 C# 遷移：英國企業指南 、COBOL 遷移至 Python - 英國企業指南 與 COBOL 遷移至 Go：英國企業指南 。

常見問題

COBOL 現代化服務包含什麼？ 一份完整的合作涵蓋現況盤點與分析、目標架構設計、資料遷移、程式碼轉換或重新託管、以比對為核心的測試計畫、平行運行、切換規劃以及知識移轉。只替程式碼轉換標價的提案，涵蓋的只是實際工作裡的少數部分。

誰提供 COBOL 到現代語言的遷移？ 有三類：工具廠商與其導入夥伴、全球系統整合商，以及獨立的專業工程公司。工具廠商提供成熟的自動化，整合商為超大規模資產提供人力規模，專業公司則為中等規模的專案提供資深工程師與工具中立性。

COBOL 現代化專案如何定價？ 常見模式是按實際投入計費、按模組或每千行的固定價，以及綁定功能等價的按成果定價。現況盤點應當單獨採購並且排在最前面，這樣後面的部分才能按證據而不是按假設來定價。

盤點之前該不該接受固定價？ 通常不該。沒有分析就報出的固定價，要嘛加了你未必用得上的餘裕，要嘛定得樂觀、註定以變更申請的形式回來。先買盤點，再用它的結論去拿後續各階段的確定報價。

怎麼驗證供應商應付得了我們的程式碼庫？ 請他們在盤點階段轉換你最難的那個模組，並把產生的結果給你看。挑一個包含組合語言呼叫、變體記錄結構與壓縮十進位運算的模組。他們交出什麼，以及答應得多爽快，比任何一通客戶推薦電話都更能說明問題。