数字化底座选型：先别谈价格，用这 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 的共同语言，比比拼功能清单更有用。
想把这篇里的做法落到自己的厂里？资源中心有对应场景的在线自测与资料模板，也可以直接约一次真实环境演示。
常见问题
围绕本篇主题的追问，先看这里；仍有疑问可联系我们
数字化底座能不能替代 ERP？
取决于边界。底座强项是流程密集、变更频繁的场景与跨系统协同；标准财务核算、税务合规等强规范领域，专用产品通常更稳。更现实的是用底座补齐 ERP 覆盖不到或改不动的环节，并打通主数据与单据。
平台自带的模板能不能直接用？
模板解决起点，不是终点。看两点：字段与口径是否贴合实际作业，以及改起来是否主要靠配置。每个模板都要大改，模板价值就有限。
私有化一定比 SaaS 好吗？
不是。私有化带来数据自主与网络隔离，代价是升级、运维、扩容自担。SaaS 在迭代与运维成本上占优，但要确认租户隔离、数据导出与合规条款。按数据敏感度与 IT 能力选。
底座化落地真的能缩短周期吗？
需求明确、场景边界清晰时能显著缩短，因为少了重复搭建基础能力的时间。需求本身没想清，底座只会让你更快做出要返工的东西。前置流程梳理不可省。
二开写多了会不会吃掉底座优势？
会。核心业务逻辑尽量用配置表达；底座外代码只用于确实无法配置的部分，并评估能否随版本平滑升级。