數字化底座選型：先別談價格，用這 8 個問題把標尺立起來
選型失敗通常不是選錯了產品，而是標尺沒立——演示很漂亮，上線幾個月後發現流程表達不了、資料搬不走、升級會打架。先問「會不會用死」，再問「用得好不好」。
讀這一篇能得到什麼
- 先分清底座承載的是「表單 + 流程」還是「業務系統」，這決定三年後要不要重做
- 流程引擎差距藏在分支、並行、回退、加簽、超時升級與版本策略裡，要用自己最複雜的流程去試
- 資料歸屬與退出成本必須在合同階段談清：全量結構與資料能否匯出、能否私有化、介面開放到什麼程度
- 多組織、多工廠、多租戶、多語言若是後期「加」上去的，代價通常高於一開始就原生支援
- 實施方的行業模板與交付延續性，比功能清單更能預測專案成敗
演示廳裡什麼都好使，回廠才知道卡在哪
廠商把採購申請、請假審批畫得很順：拖個表單、拉條流程、出張報表。你的質量變更、不合格處置、多工廠調撥不長這樣——分支多、並行多、要回退、要加簽、還要保留在途單據的舊版規則。演示廳裡點幾下「都能配」，不等於回廠能扛住真實業務。
底座看起來都差不多，真正的差距在兩處：表達上限決定你能用它做多複雜的事；退出成本決定你不想用了能不能走。價格可以後談；標尺必須先立。下面 8 個問題按「先問會不會用死，再問用得好不好」排——每個都給了可當場驗證的動作。
前四問：會不會用死
很多人把底座選型當成「平臺化底座能不能拖」，真正決定三年命運的，是它能不能扛住製造業單據的密度與狀態變化。前四問答不清，後面談價格、談工期意義不大。
1. 它承載的是「表單 + 流程」，還是「業務系統」？
這是最根本、也最多人事後才醒悟的一問。
表單型平臺擅長把紙質單據電子化：一張表、一條審批、一個列表。單點場景夠用。業務系統型底座還要具備：物料 / 供應商 / 客戶 / 裝置 / 工序等主資料的生命週期與唯一性；多表關聯與可配置業務規則；單據狀態機（執行中、部分完成、關閉、作廢等）與守衛條件；併發與事務的確定結果；數量與單位的精度與換算可控——製造業錯一位小數就是事故。
當場驗證：讓最熟業務的人描述一條真實單據從產生到關閉，含退回、變更、拆分，看對方能否主要靠配置配出來，而不是承諾「可以定製」。若對方反覆把話題拉回「我們模板很多」，而回避你的那條複雜單據，通常說明表達上限不夠，不是銷售話術問題。
2. 流程引擎扛得住分支、並行、回退與加簽嗎？
演示流程通常很乾淨。你的實際流程往往不乾淨。
| 能力 | 為什麼重要 | 怎麼追問 |
|---|---|---|
| 條件分支與動態路由 | 按金額、物料、客戶等級走不同鏈 | 現場配一條按數量區間分流 |
| 並行與匯聚 | 質量、工藝、採購同時評審 | 問並行分支回退是否重複觸發 |
| 回退與撤回 | 駁回回到哪一步、會籤是否保留 | 問回退到已辦人時原記錄是否留痕 |
| 加簽與會籤 | 臨時追加責任人、多人確認 | 問加簽是否影響後續節點計算 |
| 超時與升級 | 逾期提醒或升級 | 問時限可否按節點分別設定 |
| 代理與託管 | 請假出差授權 | 問代理人權限邊界與審計 |
| 流程版本 | 改版後在途單據走舊版還是新版 | 幾乎必問，答不清會出大問題 |
當場驗證：用你當前最複雜的那條流程（多半是變更或不合格品處置）去試，不要用採購申請這種簡單流。
3. 資料在你手裡，還是在他手裡？
三個出口要問清：全量匯出是否含表結構、欄位型別、關聯與附件（能導 Excel 不等於能重建）；API 文件、配額、Webhook、鑑權是否適合服務端對接；是否支援私有化或專有云、庫是否由你掌控、備份策略是否可自定。
捷徑：讓廠商演示「把某個業務物件連同關聯資料完整匯出，並說明重建步驟」。答得含糊，退出成本就高。
4. 二開邊界在哪，升級會不會打架？
底座一定要擴充套件，問題在擴充套件方式：常規欄位、規則、流程能否配置解決；外掛 / 鉤子 / 自定義元件的介面版本策略是否明確；擴充套件程式碼放哪、升級是否覆蓋；是否支援灰度與回滾、歷史資料如何相容。
特別警惕「什麼都靠寫指令碼」——短期靈活，長期每一行都變成升級負債。也要問清：廠商大版本升級時，你們的擴充套件是「跟著升」「凍結舊版」還是「自己合併衝突」——三種工作量差一個數量級。
後四問：用得好不好
「能用」不等於「能用得好」。集團多工廠、出海語種、實施團隊與退出條款，往往在簽約後才變成痛——那時改標尺已經太晚。
5. 多組織、多工廠、多租戶是原生的嗎？
集團製造常見訴求：集團 → 公司 → 工廠 → 車間的層級權限與資料隔離或彙總；隔離模型是獨立庫、獨立 schema，還是共享表加租戶標識——三種成本與強度差很大，必須問清；跨組織調撥、集團統一採購分發、共享主資料但各自維護業務；租戶開戶到停用與資料銷燬是否有完整流程；總部能否橫向對比各廠，而不是挨個登入。
紅線：多租戶若是後期補丁，資料隔離與權限模型常有隱患。寧可現在多問半小時。
6. 多語言與出海，是真國際化還是翻譯外掛？
看語種目錄與新增成本；缺譯時是回退原文、留空還是報錯；物料名、檢驗項等業務資料是否支援多語言（而不只是介面翻譯）；日期、數字、貨幣、地址格式；審批時限按誰的時區算。
當場驗證：切換一個語種，開啟一條真實業務資料——看是介面變了，還是資料也變了。
7. 誰來做第一個場景？
產品再好，落地靠人。問行業模板是否貼近作業口徑；能不能在真實環境用真實資料演示；交付團隊人員流動情況；對方建議的首個落地場景與理由——若建議從不痛不癢的小場景開始，通常說明心裡沒底；願不願意坦誠「這個場景我們做不了」。
8. 三年後要換，搬得走嗎？
合同階段寫清：資料與配置匯出格式、頻次、是否收費；終止後保留期與銷燬方式；表單、流程、報表等關鍵物件能否以可讀格式匯出，而不只是一份庫備份；原始碼或擴充套件程式碼歸屬。
一句話：能低成本離開的底座，才值得長期留下。 走不掉的底座，議價能力會消失。
一張評分表，和三個人的分歧
讓最懂業務的三個人分別打分，取平均。權重可調；分歧點比總分更重要——同一維度分差很大，說明需求沒講清或對方沒演示明白，都該繼續深挖。
| 維度 | 建議權重 | 關鍵判斷 | 得分 |
|---|---|---|---|
| 建模表達上限 | 20% | 無程式碼表達最複雜物件與規則 | /10 |
| 流程引擎成熟度 | 15% | 分支 / 並行 / 回退 / 加簽 / 版本 | /10 |
| 資料歸屬與可遷移 | 15% | 全量匯出、介面、部署形態 | /10 |
| 二開與升級穩定性 | 10% | 擴充套件點穩定、升級不打架 | /10 |
| 多組織與多租戶 | 15% | 是否原生、隔離模型清晰 | /10 |
| 國際化能力 | 10% | 資料級多語言、缺譯回退、時區 | /10 |
| 實施方能力 | 10% | 行業模板、真機演示、坦誠度 | /10 |
| 退出成本 | 5% | 合同條款可執行 | /10 |
不太適合硬上底座的場景
- 毫秒級產線控制——屬於 SCADA / 邊緣層
- 強演算法排產、模擬——底座不是合適載體
- 標準財務核算、法定報表——專用產品更穩
- 純一次性、做完就不再改的表單——投入過重
- 作業標準每週還在變——先固化再上，否則等於把混亂電子化
若你的痛點其實是「某個專用系統缺一塊」，而不是「大量變更頻繁的跨部門流程」，先評估補齊專用系統或做輕整合，未必需要上完整底座。底座擅長的是把組織、權限、表單、流程、報表與整合沉澱成可複用能力；把它當成萬能替代品，反而容易把邊界做糊。
標尺立住了，再談報價與排期
選型前先寫清需求優先順序與驗收標準，再用真實資料跑一遍——比被演示帶偏便宜得多。PoC 建議直接拿一條會讓你們自己頭疼的單據（含異常分支），而不是廠商準備好的幸福路徑。JEDP 以組織、權限、表單、流程、報表與整合六大引擎打底，並支援多語種執行與多租戶隔離；選型時把上述 8 問當成合同與 PoC 的共同語言，比比拼功能清單更有用。
- JEDP 平臺能力：六大引擎 / 雙智慧體 / 多語言 / 多租戶
- 資訊化選型打分表（免留資自測）
- 平臺與雙智慧體沙箱試用
想把這篇裡的做法落到自己的廠裡？資源中心有對應場景的線上自測與資料模板，也可以直接約一次真實環境演示。
常見問題
圍繞本篇主題的追問，先看這裡；仍有疑問可聯絡我們
數字化底座能不能替代 ERP？
取決於邊界。底座強項是流程密集、變更頻繁的場景與跨系統協同；標準財務核算、稅務合規等強規範領域，專用產品通常更穩。更現實的是用底座補齊 ERP 覆蓋不到或改不動的環節，並打通主資料與單據。
平臺自帶的模板能不能直接用？
模板解決起點，不是終點。看兩點：欄位與口徑是否貼合實際作業，以及改起來是否主要靠配置。每個模板都要大改，模板價值就有限。
私有化一定比 SaaS 好嗎？
不是。私有化帶來資料自主與網路隔離，代價是升級、運維、擴容自擔。SaaS 在迭代與運維成本上佔優，但要確認租戶隔離、資料匯出與合規條款。按資料敏感度與 IT 能力選。
底座化落地真的能縮短週期嗎？
需求明確、場景邊界清晰時能顯著縮短，因為少了重複搭建基礎能力的時間。需求本身沒想清，底座只會讓你更快做出要返工的東西。前置流程梳理不可省。
二開寫多了會不會吃掉底座優勢？
會。核心業務邏輯儘量用配置表達；底座外程式碼只用於確實無法配置的部分，並評估能否隨版本平滑升級。