企業軟體開發服務：你到底買到了什麼

企業軟體開發服務這個說法，照大多數開發公司網站上的用法，指的就是同樣的工作貼上一個更大的數字。團隊一樣，流程一樣，提案裡多了一面客戶標誌牆，價格翻了三倍。買方心裡有數，所以採購部門早就學會略過這個詞，直接去讀合約附件。

底下確實有一個真實的區分，而且它跟公司規模無關。一家 40 人的保險公司可以跑一個貨真價實的企業級專案，一家 12,000 人的零售商也可能只是訂了一個網站。區分它們的是這套系統加在建置方身上的義務：它必須跟多少其他系統對話，允許停多久，誰能否決一次上線，哪個主管機關對它有興趣，以及供應商撒手不做時會發生什麼事。

以下用這些義務來定義這個類別，好讓買方分得出誰扛得住，誰只是替一個普通專案加了一張企業級的封面。

到底是什麼讓一個軟體專案成為企業級？ 不是買方的規模。一個專案成為企業級，是因為它背著普通專案沒有的約束：寬闊的整合面、合約上的可用性與復原義務、法規暴露、幾個各自都能擋下一次上線的利害關係人群體、會壓垮樸素設計的資料量，以及必須與如今沒人理解的系統共存。決定架構與大部分成本的是這些約束，不是功能清單。

什麼讓一個專案成為企業級

有用的判準是一份約束清單，一個專案背上其中大多數而不是某一條時才算數。誠實地套用它，會把很多號稱企業級的東西排除掉，同時把那些當成小案子來賣、也因此按小案子估算而失敗的工作包括進來。

整合面

數一數你的新軟體必須跟多少系統交換資料，再數一數擁有這些系統的團隊與廠商有幾個。能預測成本的是第二個數字。由一個內部團隊擁有的三條整合是兩週的工作。由三家廠商各自擁有的三條整合，每家都有自己的變更視窗、沙箱可用時間與支援窗口，那是一季的工作。

每個所有方都會帶進一份你控制不了的時程。一家每月更新沙箱的廠商決定了你的測試節奏，一家認證要六週的支付服務商決定了你的上線日期。當對口超過十家，整合行事曆就成了專案計畫本身，開發只能塞進縫隙裡。

可用性義務

普通軟體被期待能動。企業軟體的這份期待後面跟著一個數字，通常寫在一份帶服務補償的合約裡。這個數字最先改變的是架構，因為單一執行個體的部署不論程式碼多好都守不住它。

從一個容忍維護視窗的目標，跨到一個不容忍的目標，是多數企業預算裡最貴的一行，而且經常由從沒看過這個價錢的人拍板。我們談有實質意義的可用性 SLA 的文章講了這些數字怎麼寫，以及它們如何被常態性地寫壞。

有否決權的利害關係人

普通專案有一位產品負責人。企業專案有產品負責人、資訊安全部門、資料保護長、採購負責人、擁有網路的基礎架構團隊、將來要接下支援工作的服務台，還常常有臨床、法務或法遵的審查人。

他們之中任何一位都能擋下一次上線，而且沒有一位是向出錢的人報告。於是決策要花掉與難度無關的行事曆時間，沒把這件事寫進計畫的供應商，從第二個月起會錯過每一個日期。

已經沒有人再理解的系統

每個企業環境裡至少有一套系統，它的行為只有輸出可以佐證。寫它的人已經走了，規格文件就算還在，描述的也是更早的版本。它能跑，它承重，而且大家認為改它不明智。

新軟體必須與它共存，所以得先有人弄清楚它實際在做什麼。那是考古，不是開發：讀正式環境的資料、追蹤呼叫、對副本做受控實驗、把程式碼隱含的規則寫下來。在大環境裡這是好幾週的工作量，也因為產不出看得見的功能，成為談判時最常被刪掉的項目。

刪掉它只是把工作挪到整合測試，讓已經在修缺陷的人在時間壓力下發現它。一個把探查單獨報價、而且守得住這筆錢的供應商，是在告訴你一件關於這類專案如何失敗的真話。我們談舊系統現代化，重寫還是重構 的筆記講了這場考古會挖出什麼。

採購佔掉一半的工作

多數技術人員把這部分低估了三倍。在一次真正企業級的合作裡，從第一次談話到第一行程式碼之間的工作比第一個交付增量還長，而且消耗雙方的資深人力。

自 2025 年 2 月 24 日起，英國公部門依 Procurement Act 2023 運作，投標公共合約的供應商必須在擴充後的 Find a Tender 服務裡註冊到中央數位平台上。私部門的採購沒有對等的單一入口，這反而讓它更慢，因為每個買方都自己發明了一套。

資安問卷

你會收到一個試算表。它會問你的開發生命週期、存取控制、修補的節奏、分包商、資料存放地、事件回應時間與背景調查。較大的買方會寄來好幾百題，一家銀行或一個 NHS 信託會寄得更多。

問題本身不難，但只有在答案已經以政策形式存在時才答得出來。一個在投標過程中才第一次拼湊這些答案的供應商要花四到六週，而且會答錯幾題。做過一次的供應商，從一份持續維護的答案庫裡幾天就答完了。這是偏向他們的正當理由。

廠商準入、保險與財務查核

準入與投標是兩回事，而且常常並行。你會被要求出示買方指定額度的專業責任險與網路責任險、雇主責任險，有時還有產品責任險。企業買方常要求小型顧問公司預設沒有的賠償上限，而在投標中途把保額拉高是要時間的。

接著是財務查核。買方會調閱申報過的財報，跑一次信用評分，在更大的合約上還會要管理報表或母公司保證。資產負債表撐不起合約金額的供應商，不論技術上多優秀都會被排除，這就是有能力的小公司為什麼會輸掉本來適合它們的標案。

業務週期為什麼比第一個增量還長

把兩條時間軸並排放，問題的形狀就清楚了。資格確認、需求、資安審查、法務協商、保險舉證與準入手續，在一份價值數十萬 GBP 的合約上通常要佔掉四到九個月。而開工之後第一個有用的軟體增量，可能十週就出來了。

在這個週期開頭寫下的估算，到簽約時已經過期，一個在這段空檔裡堅持固定價格的供應商，不是加了很厚的水分，就是打算日後就範圍吵一架。技術假設同樣會老：投標時還是現行版本的東西，到啟動時可能已經不再受支援。

替每一份估算標上日期，寫清它的前提，並在簽約時約定一次重新定基準，而不是假裝那個數字活了下來。堅持原始數字有效的買方，買到的是一條變更申請生產線。我們談怎麼寫一份能拿到有用報價的軟體 RFP 的指南講了這份文件裡該有什麼。

真正的交付物是非功能需求

功能清單容易寫，也很少決定什麼。決定架構、基礎架構帳單、團隊規模與測試週期長度的是非功能需求，而在多數企業專案裡，它們在一份功能清單長達四十頁的文件中只有兩段。

這種失衡是最可靠的超支徵兆。一個把第一次工作坊整場花在可用性、復原、延遲、吞吐量、可稽核性與保存期上的供應商不是在拖延：這六個數字會砍掉大部分架構選項，而晚了再定就等於重建。

把它們寫成帶數字與條件的可測試敘述。「系統必須高可用」不是需求。「訂單服務必須維持在負載平衡器上量測的月度可用性 99.9%，提前五個工作天通知的兩小時視窗除外」才是，因為測試可以判它不合格。

用白話講復原點與復原時間

這些數字裡有兩個比任何功能都更能推高成本，而且經常被把意思弄反的人掛在嘴上。復原點目標 (RPO) 是你願意丟多少資料：RPO 一小時代表你接受災難之後最多丟掉一小時的交易，而你的備份或複寫方案必須保證不會比這更糟。復原時間目標 (RTO) 是你願意停多久，所以 RTO 四小時代表服務要在事故開始後四小時內重新處理流量。

兩個數字都直接翻成架構。AWS 在它的災難復原指引裡列出四個大方向：備份與還原、試點燈、暖待命，以及多站點雙活。它們從便宜而慢排到昂貴而幾乎即時，而一旦這兩個目標談定，選擇就替你做好了。

不要因為聽起來負責任就答應激進的數字。RPO 為零加上分鐘級的 RTO，代表持續複寫與第二套線上環境，基礎架構帳單大致翻倍。我們談小型軟體團隊的災難復原 的文章說明了較便宜的等級買到的是什麼。

可用性算術，以及一份 SLA 實際買到什麼

可用性百分比把意思藏在小數點後面。在一個 30 天的月份裡，99.9% 允許大約 43 分鐘的停機，99.95% 允許大約 22 分鐘，99.99% 允許大約 4 分鐘。這是整個月的全部預算，包含部署、憑證更新，還有那次比預想更久的資料庫切換。

每月 4 分鐘，對一個在上班時間部署、只呼叫一名工程師的團隊來說做不到。它需要每一層的備援、自動切換、不中斷流量的部署，以及凌晨三點還醒著的人。最後這一項通常比基礎架構還貴，而且幾乎從不在原始預算裡。合約裡也要把量測點定死，因為在負載平衡器上讀到的可用性，跟從真實使用者遙測讀到的可用性，同一次事故可以差一個數量級。

延遲、吞吐量，以及那份沒人量過的負載

延遲目標需要一個百分位與一個範圍，因為平均值會把失敗蓋住。「結帳端點在每秒 400 個請求下第 95 百分位 200 毫秒」這樣的目標可測。「快」不可測，平均值也一樣，因為平均 200 毫秒完全可以跟二十個使用者裡有一個等四秒並存。

吞吐量需要的是尖峰，不是平均。零售商照聖誕節前的星期五抓量，薪資系統照當月最後一個工作天，公部門服務照通知信上寫的截止日。照年度平均抓量，就是新系統在第一個忙碌小時裡垮掉的原因。尖峰從現有系統的日誌裡取，十比一的比例很常見，而這個比例決定了設計裡要不要一個佇列。

可稽核性與保存期

受監理的買方，以及越來越多不受監理的買方，需要在很多年之後回答誰在什麼時候改了什麼。那是一項設計要求，不是一項日誌設定：一個會覆寫資料列的系統答不出來，而這個答案必須活到保存政策規定的期限。

早點定下三件事。哪些事件要稽核，通常是對具有法律或財務意義的紀錄的狀態變更，而不是每一個 HTTP 請求。每一類紀錄保存多久，這是一個法律問題，還掛著一條資料保護約束，因為把個人資料留得比必要更久本身就是違規。以及誰能讀這條軌跡，因為管理者可以改的稽核紀錄什麼也證明不了。保存與刪除權在這裡衝突，而這份張力是在資料結構裡解決的，不是在政策裡。

買方會要的那些認證

反覆出現的有三個，它們不斷被混為一談，而它們證明的是不同的東西。一個說不清差別的供應商並不持有它們。

Cyber Essentials 與 Cyber Essentials Plus

Cyber Essentials 是英國政府支持的基準線，由 NCSC 制定，透過其官方交付夥伴 IASME 提供。它涵蓋五項技術控制：防火牆、安全組態、安全更新管理、使用者存取控制與惡意軟體防護。基本等級是一份經獨立複核的自評問卷，NCSC 列出的價格依組織規模從 GBP 320 外加加值稅起。

Cyber Essentials Plus 是同樣這五項控制，由獨立的技術稽核來驗證而不是靠宣稱。評估方會做內部與外部的弱點掃描，並抽樣測試使用者裝置、網際網路閘道與面向網際網路的伺服器。Plus 稽核必須在基本認證之後三個月內完成，兩張證書的效期都是十二個月。

這套制度在商業上跟技術上一樣要緊。自 2025 年 2 月 24 日起對中央政府部會、其下屬機構、非部會公共機構與 NHS 機構生效的 PPN 014，要求供應商在處理公民個人資訊、政府雇員個人資訊，或處理 OFFICIAL 等級資料的 ICT 系統時必須持證。

ISO/IEC 27001

ISO/IEC 27001 是資訊安全管理系統的國際標準，由 ISO 與 IEC 發布。現行版本是 ISO/IEC 27001:2022，2024 年的第 1 號修訂案依照 ISO 管理系統標準整體的一項變更，在組織環境相關條款裡加入了氣候行動的文字。

它是一份管理系統標準，買方誤讀的正是這一點。它並不規定一套每家獲證組織都實作了的固定控制。它要求組織界定自己的範圍、評鑑風險、選擇控制，並執行一個有文件的審查與改進循環。證書由取得認證資格的驗證機構在稽核之後核發，不是由 ISO 自己核發。

所以有用的問題從來不是供應商有沒有它，而是證書上的範圍聲明涵蓋了什麼。一個只限於總部職能的範圍，對那支握著你原始碼與正式環境憑證的團隊什麼也沒說。把證書要過來，讀那段範圍。

SOC 2

SOC 2 是美國的東西，性質也不同。AICPA 把它定義為「一份關於服務組織中與安全性、可用性、處理完整性、機密性或隱私相關的控制的報告」，依其信任服務準則執行。它是由會計師事務所出具的確信報告，不是證書，沒有及格線也沒有可以掛出來的標誌。

真正要緊的差別是類型。Type 1 報告描述這些控制，並評估它們在某個時間點上設計是否適當。Type 2 報告則測試它們在一段期間內是否有效運作，通常是六個月或十二個月。Type 1 是一張照片，Type 2 是一段影片，把 Type 1 當成等價物接受的買方，收到的東西遠比他們以為的少。

讀報告，別讀封面。稽核人員記錄哪些控制沒有照描述運作的例外章節才帶著資訊，而那正是供應商希望你跳過的部分。

它們都證明不了的事

三者沒有一個能證明你的軟體是安全的。Cyber Essentials 涵蓋的是基礎架構衛生的一條基準線。ISO 27001 涵蓋的是這個組織有沒有把安全當成一個過程來管理。SOC 2 涵蓋的是宣稱過的控制在一段期間內是否運作過。三者關心的都是供應商，不是產品。

應用程式安全是另一門學科，證據也另有一套。要最近一次滲透測試報告及其修補狀態，而不是那面證書牆，並且看清是誰做的、針對什麼範圍做的。這就是我們滲透測試服務背後的實質。

依產業區分的法規暴露

通用的企業級建議在法規這裡會變得不安全。以下只列出可查證的義務，不越界到法律意見，那應該由有資格的顧問提供。

幾乎適用於所有人的英國 GDPR

如果系統碰到個人資料，英國 GDPR 第 32 條同時適用於控管者與處理者。它要求適當的技術與組織措施，並點名了四項：假名化與加密，處理系統持續的機密性、完整性、可用性與韌性，事故之後及時復原個人資料可用性與存取的能力，以及一套定期測試與評估這些措施有效性的流程。

把第三項再讀一遍，因為它把災難復原變成一項資料保護義務，而不是維運上的偏好。ICO 的資料安全指引把 Cyber Essentials 指為一條有用的基準線，同時明講它只是一組基礎控制，不會涵蓋每個組織的處境或每項處理活動的風險。

金融與醫療，簡短而謹慎

在金融服務領域，FCA 的營運韌性制度要求在管轄範圍內的機構辨識重要業務服務，替它們設定影響容忍度，並能在嚴重但可能發生的中斷期間維持在容忍度以內。過渡期已於 2025 年 3 月 31 日結束，所以這項義務是生效的，它決定了這些機構的供應商必須拿出什麼證據。

在醫療與照護領域，一套醫療 IT 系統會觸及 NHS England 的臨床風險管理標準：面向製造方的 DCB0129，以及面向導入方組織的 DCB0160。兩者都在國家層級的檢討之中，公開諮詢從 2026 年 6 月 29 日進行到 2026 年 9 月 11 日，所以在倚賴任何摘要（包含這一篇）之前，請先確認目前的狀態。

如果這裡沒點到你的產業，就按通用辦法處理這項義務：找出主管機關，讀它自己公布的要求，並讓供應商針對那些要求舉證，而不是拿一段泛泛的保證敘事來搪塞。

錢花在整合架構上

企業級成本集中在系統之間的接縫裡，不在系統內部。功能通常是清楚的。讓六套資料模型不同、對「客戶」的理解也不同的系統達成一致，才是時程消失的地方。

點對點還是中介

點對點是預設選項，因為第一條整合確實這樣比較簡單。代價是組合式成長：n 套系統直接對話，連線數會朝 n 的平方走，每條都有自己的重試邏輯、憑證與監控。四套系統時沒問題，十五套時就維護不動了。

一個中介或事件匯流排會把這條曲線反轉過來。它增加一個元件、一份維運負擔，以及一個需要在設計上繞開的單一失效點，通常在第六到第八個參與方時開始回本。錯誤在兩個方向上都會犯：小環境買了它們不需要的整合平台，大環境則一直拖到網狀連線已經硬化。

同步還是事件驅動

同步呼叫容易推理，也會把可用性耦合在一起。如果你的服務內嵌呼叫四套系統，而每套都有 99.9% 的上線時間，那麼在你寫出第一個 bug 之前，你自己的上限大約是 99.6%。每一條同步相依，都是把你自己可用性的一份交給別人的維運團隊。

事件驅動的設計解開了這層耦合，代價是最終一致性與難得多的除錯。把同步呼叫留給使用者正在等待、且過期答案不可接受的路徑，其餘的都搬到事件上。這件事按每次互動來決定，而不是當成一種家規。

冪等、重播與對帳

分散式系統會把訊息投遞不只一次，偶爾還會弄丟，所以每一條跨邊界的寫入路徑都必須可以安全重複。已經確立的做法是由用戶端產生冪等金鑰。Stripe 的實作會保存某個金鑰第一次請求的狀態碼與回應內容，在重試時回傳同樣的結果，至少 24 小時之後清理金鑰，並在同一個金鑰帶著不同參數到來時報錯。

重播是同一個想法的維運另一半。當一個下游系統不可用了六小時之後，得有人把錯過的訊息推過去，而這只有在消費端是冪等的、而且訊息被保留下來時才安全。把保留視窗與重播機制跟正常路徑一起設計，因為事後補上等於改動每一個消費端。

對帳常被當成事後補丁，它不該是。它是一個排程作業，比較兩套本該一致的系統的狀態，回報差異，然後不是修正它們就是交給人處理。沒有它，跟財務系統之間一次無聲的偏離會在幾個月後由稽核人員發現。把它當成有負責人與告警路徑的一級交付物列進預算，而不是最後有人隨手寫的一支腳本。

與舊系統共存和絞殺榕

整套換掉一個還在跑的系統，是可選項裡風險最高的一個，而它被選中的頻率遠高於應該的次數。漸進式的替代做法由微軟記錄為絞殺榕模式：在舊系統前面放一層外觀，讓請求從它經過，再把功能一塊一塊搬過去，直到老系統沒有流量可接，就可以關掉。

每一個增量都獨立有價值，也獨立可回復：如果第三塊搬砸了，就把它繞回去。微軟明講了它不適用的場合，也就是無法攔截送往後端的請求時、無法修改舊有原始碼時，或者系統小到直接整套換掉更省事時。

有兩個細節決定它能不能成。外觀絕不能變成瓶頸或單一失效點，所以它需要跟它背後的服務同樣的可用性工程。而過渡期間的跨系統呼叫需要一層防腐層，好讓舊有的語意不滲進新設計。資料比流量更難：把一個領域的資料表搬出去，代表一次初始載入、一條變更資料擷取的串流、一段兩邊都寫並做比對的驗證期，然後才是切換，而且在舊有物件被刪除之前都還能回復。

企業規模上的測試

企業專案的測試與其說是工程問題，不如說同時是後勤問題，也是樂觀計畫死掉的地方。

環境

你需要的會比預算裡的多：開發環境、一個接到對口沙箱上的整合環境、一個夠貼近正式環境以至於數字有意義的效能環境、一個穩定到能讓忙碌的非技術人員使用的驗收環境，還有正式環境。每一個都有基礎架構成本、一套更新流程與一位負責人。總是被砍掉的那個是效能環境，而省掉它就代表在正式環境做負載測試。

測試資料與個人資料難題

企業系統需要真實的資料來測試，而真實的資料就是正式環境的資料，裡面裝著個人資訊。把它複製到測試環境屬於英國 GDPR 之下的處理行為，第 32 條的義務也一路跟過去，包含存取控制與承載它的那個環境的安全性。

站得住腳的答案是匿名化，它必須不可逆才能把資料帶出法規範圍；或者假名化，它降低風險但仍在範圍之內。兩者都需要工程工作來保住讓這些資料有用的統計形狀，還需要一套有文件的流程。把正式環境資料庫還原到一個共用測試環境很常見，在很多組態下並不合法，而且正是一次供應商評估想要暴露出來的事情。

效能測試

效能測試回答的是系統能不能達到之前談定的吞吐量與延遲數字，所以只有那些數字被寫下來它才可能存在。測尖峰型態而不是平均，而且要包含尖峰的形狀，因為十分鐘內爬升跟一秒內跳升會觸發不同的失效模式。

在正式環境等級的資料量上跑。一個在 10,000 列上瞬間回應、在 4,000 萬列上完全不能用的查詢，是企業軟體裡最常見的效能缺陷，而它在小資料集上根本看不見。

由另有本職工作的人來做驗收測試

驗收測試通常被排成兩週的視窗，也是最可靠會超期的階段，因為測試者就是業務專家，而業務仍然需要他們。他們每週只能給你幾個小時，到月底他們的可用時間會歸零。

在合約裡點名測試者，談定每週的時數，事先把情境寫成腳本而不是請人自由探索，並把缺陷分類當成一場聯合會議來開，而不是一條工單佇列。一個報了兩週驗收測試卻說不出參與者名字的供應商，沒有真正跑過一次。

交付模式與治理

行得通的團隊型態是小而穩定，不是大而輪替：一位為整個專案架構負責的技術主導、三到六名工程師、一位處理對口行事曆的交付主導，以及共用的品質工程師與基礎架構專家。中途加人可靠地會讓專案變慢，因為瓶頸是脈絡，不是人手。

在第一個衝刺之前把決策歸屬寫下來。指定一個人可以核准範圍變更，一個人可以核准架構取捨，一個人可以驗收上線。如果那是三個名字，決策要幾天。如果那是三個委員會，決策要幾週，而計畫是虛構。

指導會議的節奏讓一個長專案保持誠實：每兩週跟工作小組做一次交付檢視，每月把預算持有人與擁有否決權的人拉進同一個房間做一次指導會，以及一份對照原始基準而不是上個月修訂版的書面狀態報告。一個狀態永遠是綠燈的供應商不是在管理風險，是在藏風險。

商務模式，以及風險由誰承擔

四種模式幾乎涵蓋了全部，每一種把風險放在不同的地方。問題不是哪一種最好，而是眼前這份不確定性由哪一方來扛比較合適。

實作實銷適合真正不確定的工作：探查、舊系統考古，或者對著一個文件很差的對口做整合。買方承擔風險並取得完全的彈性，這需要信任，也需要有人真的盯著消耗速度。

帶上限的實作實銷加了個天花板，通常是那個明智的折衷，我們大多數軟體開發服務也是這樣組織的。超過上限的部分由供應商吸收，買方在上限以下只為用掉的部分付錢，雙方都把範圍維持得誠實。上限裡應當帶上百分之十五到二十五的餘裕，因為一個按期望成本封頂的供應商，不是算錯了就是正在籌劃一份變更申請。

固定價格只有在範圍真正固定時才成立，而在企業專案裡，這對一個增量成立，對整體不成立。六到十週的固定價格增量，每一個都在上一個落地之後再定範圍，能給出預算確定性，又不必假裝有人能把十八個月的事提前寫清楚。

託管服務是系統上線之後的正確型態：一筆按月的費用，涵蓋支援、修補、監控與一份定額的變更額度，按建置成本的年度百分比定價，而不是按人頭。讓服務定義裡寫明回應時間與升級路徑。

企業軟體開發服務：什麼在推高成本

按影響大小排列的成本驅動因素

這個順序會讓人意外，因為功能排在最後。第一位是整合面，具體說是外部所有方的數量，而不是端點的數量。第二位是非功能目標，因為從一個可以停維護視窗的服務跨到一個不能停的服務，會改變設計的每一層。

第三位是保證與法規負擔：投標時間、證據製作、稽核支援，以及在整個合約期內都更慢的上線流程。第四位是資料移轉與對帳，它被一貫低估，因為難點在舊資料的品質而不是資料量。第五位是利害關係人群體的數量，它決定決策延遲。第六位是環境數量。功能範圍排第七，而它通常是原始預算裡唯一的一項。

英國的參考價格區間

下面的區間是我們從英國專案得來的內部估算，以第一年成本表示，含探查、建置、測試與上線，但不含買方自己的人力時間。它們是參考而不是報價，區間之所以寬，是因為上面那些驅動因素會推動它們。

不用表格也能說清：一個有兩三條整合、面向內部使用者、目標 99.5% 的單一服務，第一年落在 GBP 120,000 到 GBP 250,000 之間。一個有五到八條整合、99.9% 的面向客戶部門級系統，是 GBP 300,000 到 GBP 700,000。一個取代舊系統、有十到二十條整合、目標 99.95% 的核心平台，是 GBP 900,000 到 GBP 250 萬。一個 99.99% 的跨多法人受監理專案，從 GBP 250 萬 左右起跳，並往上走。

預算裡沒有的維運成本

在這之上還要加上每年的維運成本，在算進支援、代管、修補、資安工作與一份適度的變更額度之後，它落在建置成本每年的百分之十五到二十五之間。一份只給建置出錢、不給維運出錢的預算，產出的是一個在第二年肉眼可見地衰敗的系統，我們對軟體維護成本的拆解講了這筆錢都花到哪去了。

退場與延續性

一個你離不開的供應商，是一份坐在你資產負債表上的風險，而且它是最常被留到協商末尾、沒人再留意時才處理的條款。有四件事讓退場成為可能。

原始碼與它的歷史應當放在一個買方擁有、或可憑通知接手的儲存庫裡，連同建置管線與基礎架構定義。沒有建置管線的程式碼是一份檔案庫，不是一項可用資產。

文件應當足以讓一個稱職的第三方營運這套系統：架構、整合契約、針對真實發生過的失效模式的操作手冊，以及憑證清單。我們談會被人真正讀的技術文件 的文章講了什麼能撐過一次交接。

原始碼託管應對的是供應商倒下而不是離開，做法是把原始碼存放在第三方處，在約定的觸發條件下釋出。當供應商相對合約金額偏小時，它值得有；而且值得仔細讀，因為一份未經驗證的存放釋出的是編譯不了的程式碼。我們在軟體原始碼託管，到底誰需要它 裡討論過它什麼時候站得住腳。

最後，把交接在合約裡定好價。一個按談定費率計的、經通知觸發的、指定天數的知識移轉，把一場爭吵變成一張發票。同樣的紀律也適用於你的供應商的供應商，我們在談軟體供應鏈安全的筆記裡講過。

一次會面裡判斷供應商的企業級底氣

五個問題能在一小時裡問出大半，而猶豫本身跟答案一樣說明問題。

問他們交付過哪些可用性與復原目標，以及可用性是怎麼量的。一個扛過 99.95% 義務的供應商，不用提示就會說出量測點與待命安排。沒扛過的會泛泛地談備援。

要看他們 ISO 27001 證書上的範圍聲明，或者他們 SOC 2 Type 2 裡的例外章節。對持有它們的供應商來說這兩件都是尋常請求，對只有一個標誌的供應商來說則很尷尬。然後問他們在正式環境裡怎麼處理過一次對帳差異，這是沒辦法從理論上答出來的。

問他們最近三個專案各超支了多少、為什麼。所有人都會超支，有資訊量的是他們知不知道那個數字。然後問他們的退場流程長什麼樣，用天數與交付物來說。一個把這件事寫下來的供應商，預期自己會因此被評判。

這給買方留下了什麼

企業級這個詞應當描述義務，而不是一個價格帶。一旦整合面、可用性與復原目標、法規暴露與退場條款都寫了下來，候選名單會自己排出來，因為大多數供應商沒辦法針對這四項拿出證據。

Mecanik 透過我們的軟體開發服務承接這種型態的合作，保證這一側則透過滲透測試服務。如果你還在拼裝需求而不是拼裝候選名單，技術盡職調查清單是個不錯的起點，而那些非功能數字值得最先爭論。

常見問題

什麼算是企業軟體開發？ 企業級由約束定義，而不是由買方的規模定義。一個專案符合條件，是因為它有一個由多方擁有的寬闊整合面、一項合約上的可用性與復原義務、法規暴露、幾個各自都能擋下上線的利害關係人群體、會壓垮樸素設計的資料量，以及必須與沒人完全理解的舊系統共存。一家大公司可以訂一個普通專案，一家受監理的小公司也可以訂一個貨真價實的企業級專案。

在英國做一個企業軟體開發專案要花多少錢？ 照我們從英國專案得來的內部估算，一個有兩三條整合、可用性目標 99.5% 的單一服務，第一年是 GBP 120,000 到 GBP 250,000。一個 99.9% 的面向客戶部門級系統是 GBP 300,000 到 GBP 700,000。一個取代舊系統的核心平台是 GBP 900,000 到 GBP 250 萬。再按建置成本每年加上百分之十五到二十五，用於維運與支援。

企業級供應商需要 ISO 27001、Cyber Essentials 還是 SOC 2？ 它們證明的是不同的東西。Cyber Essentials 是英國政府支持的五項技術控制基準線，其 Plus 等級由獨立技術稽核驗證，並被 PPN 014 要求用於許多公部門合約。ISO/IEC 27001:2022 驗證的是一套資訊安全管理系統，所以證書上的範圍聲明比證書本身更要緊。SOC 2 是由會計師事務所出具的美國確信報告，只有 Type 2 才測試控制在一段期間內是否運作過。

什麼是復原點目標與復原時間目標？ 復原點目標 (RPO) 是你接受在災難之後丟掉多少資料，所以 RPO 一小時代表最多可能丟掉一小時的交易。復原時間目標 (RTO) 是你接受服務不可用多久，所以 RTO 四小時代表服務必須在四小時內重新處理流量。兩者比任何功能都更能推動架構與成本，因為它們要在備份與還原、試點燈、暖待命與多站點雙活之間做出選擇。

企業軟體合約裡關於退場應該寫什麼？ 四件事。對原始碼儲存庫、建置管線與基礎架構定義的所有權或可移轉的存取權。足以讓一個稱職的第三方營運這套系統的文件，包含操作手冊與憑證清單。在供應商相對合約金額偏小時的原始碼託管，而且是經過驗證的存放而不是未經驗證的。以及一條定了價的交接條款，寫明知識移轉的天數與費率，好讓離開成為一張發票而不是一場爭議。