选型判断

定制开发还是买标准品,怎么判断

这个问题很少能靠比价解决。真正决定答案的是两件事:需求还会不会变,以及这套软件将来要装在多少种机型上。把这两个维度画成四象限,结论基本是唯一的。

两个维度就够了

选型讨论常常陷在功能对比表里:这家有那个模块、那家没有这个接口。 功能表不是没用,但它回答不了「该走哪条路」, 因为几乎所有标准品的功能表看起来都够,而几乎所有定制方案都承诺能做到。 更有效的判断只需要两个维度。

维度一:需求稳定度

工艺流程、业务规则、要采集的数据项,现在能不能写成一份清单并且半年内不大改? 判断依据是三个具体问题:工艺在最近一年改过几次? 终端客户的验收要求文档化了没有?数据项与业务规则能否现在就列全? 三点都有确定答案就是稳定;工艺还在验证、客户要求还在口头讨论、 数据项每周都在加,那就是不稳定。

维度二:机型复用度

这套软件将来要装在几种机型、多少台设备上? 是只服务眼前这一台特殊设备,还是要成为一个批量出货机型的标配? 这个维度直接决定开发成本能被摊到多少台上, 也决定按台收费的第三方授权最终会累计成多大一笔钱。 两个维度交叉出四个象限,每个象限的结论都比较明确。

四象限的结论

象限特征建议
需求稳定 + 复用度高 工艺定型、要长期批量出货的机型 定制开发,并且要源码。开发成本摊到几十上百台上单台很低,源码在手意味着后续机型迭代不受制于人,也能避免每台设备付授权费
需求稳定 + 复用度低 工艺明确但只做一两台的专机 先看标准品能不能配出来。能配就买标准品;配不出来(非标协议、多轴协同、专有算法)就定制,但可以选授权使用而不要求源码交付,降低费用
需求不稳定 + 复用度高 新机型在验证阶段,未来要批量卖 分两步走。先用标准品或最小可用版本把流程跑通、把需求跑清楚;工艺定型后再做定制。这一步不能省,需求不清就定制会付大量返工
需求不稳定 + 复用度低 一次性项目、探索性验证 买标准品,配置化解决,不要写代码。这个象限里定制的每一分钱都有可能白花,因为需求变完之后代码结构大概率不适用

有一个反直觉的结论值得单独说:需求不稳定的时候不要急着定制。 很多设备厂的直觉是「反正要改,不如一开始就找人定制,改起来方便」, 但实际发生的是需求每变一次,已写好的界面、数据结构、状态机就要动一遍。 需求不稳定阶段的正确目标不是把软件做好, 而是用最低成本把需求搞清楚。

中间路线:标准品加二次开发

实际项目里用得最多的是中间路线:买一个平台化产品打底, 在它上面做二次开发补齐特殊需求。 这条路线在合适的边界内非常划算,越界之后就变成最坏的选择。

判断项在边界内(适合)已越界(应转定制)
二次开发占比不超过整体功能的三分之一,主要是界面定制、报表、少量业务规则超过一半,核心逻辑都要自己写,平台只当了个外壳
扩展方式用平台提供的官方扩展点:脚本、插件接口、自定义驱动接口要靠外挂程序、直接改平台数据库表、内存注入之类的手段绕限制
实时性要求数据采集、监控、报表这类非实时闭环需要毫秒级运动控制闭环或与视觉结果强耦合的时序控制
协议覆盖平台已内置所需协议,或提供自定义驱动的开放接口核心设备协议平台不支持且无法自行扩展
升级影响二次开发部分与平台版本解耦,平台升级不影响依赖平台的未公开行为,每次升级都要回归重测甚至重写
授权成本按点数或按站授权,单台成本可接受机型批量大,每台授权费累计后超过定制开发的总投入
交付限制可以白标或允许随设备转售授权条款禁止转售给终端客户,或必须暴露第三方品牌

表里授权成本与交付限制两行在选型阶段最常被忽略, 但对设备厂影响最大:软件里如果嵌了一个按台收费的第三方平台, 那笔费用会一直跟着出货量走;如果授权条款还限制随设备转售 或要求保留第三方品牌标识,在投标时就是明显劣势。 这两点必须在选平台时就把条款看清。

平台化能力与定制之间也不是非此即彼。 敏洽 SCADA 数采与监控软件 内置 45 个协议驱动,机器视觉检测软件 的 30 多个算法可按模块授权——通用部分已做成可复用资产, 项目上只需在这之上补业务逻辑, 相当于把「标准品加二次开发」的经济性和定制开发的自由度合在一起。

决定走定制之后,还要防两件事

交付物不完整

只拿到一个源码压缩包,没有部署文档、没有接口文档、没有点表、没有构建说明, 接手的人只能重写。定制的价值在于长期可维护,交付物缺项会直接抹掉这个价值, 所以交付清单要在合同里逐条列明,验收时按清单核。

分层不清导致无法复用

如果通信驱动、算法、界面组件与具体项目的业务逻辑纠缠在一起, 下一个机型还是要从头写,复用度高这个前提就落空了,成本优势也不存在了。 要求供应商在架构上把通用底层与业务层分开,这一条应当写进技术要求。

归属模式上敏洽提供两种:授权使用(交付可执行程序, 软件著作权归敏洽,客户获得使用授权), 以及源码交付(项目定制部分源码交付客户、该部分知识产权由客户享有, 通用底层框架的权利由敏洽保留)。两种都支持白标交付。 分工上软件与算法由敏洽负责,硬件采购、机械安装与电气接线由客户负责, 需要时可推荐长期合作的供应商对接。 具体条款与验收标准的写法见 上位机软件外包怎么切分才不留坑, 服务范围见 非标工控软件定制, 或致电 400-814-5288 先聊清需求稳定度与机型规划再谈方案。

常见问题

看三点:工艺流程在最近一年内改过几次、终端客户的验收要求是否已经文档化、要采集的数据项与业务规则能否现在就写成清单。三点都能给出确定答案,说明需求稳定;如果工艺还在验证阶段、客户要求还在口头讨论、数据项每周都在加,那就是不稳定。需求不稳定时先做定制不划算——会付大量返工成本;先用标准品跑起来,把需求跑清楚了再决定是更现实的做法。
不一定,但要看单台的特殊性有多强。复用度低且需求也不特殊,买标准品配一配是最省的。复用度低但工艺极特殊、标准品根本配不出来(比如需要多轴协同的运动控制逻辑、非标协议、专有算法),那还是得定制,只是这种一次性定制要接受较高的单台成本,或者接受授权使用而不要求源码交付以降低费用。
当二次开发的量超过标准品本身功能的一半时。这时候你同时承担了标准品的授权费、被平台架构限制的开发效率、以及升级时二次开发部分可能失效的风险——三种成本叠加,比直接定制更贵也更脆弱。判断信号很直接:如果发现要靠大量脚本、外挂程序、改数据库表来绕开平台限制,就该停下来重新评估架构了。
两个动作。一是要求交付物完整:源码之外还要有部署文档、接口文档、点表与构建说明,缺任何一项都会让接手的人重写。二是要求底层与业务分层:通信驱动、算法、界面组件这些通用部分独立于具体项目的业务逻辑,这样下一个机型能复用底层只改业务层。敏洽的做法是定制部分源码可交付且知识产权由客户享有,通用底层框架的权利保留在敏洽,客户获得随软件使用的权利——这样既能复用又不必每次重写底层。

有具体设备清单或工件样品,可以直接给判断

提供设备型号、PLC 品牌与需要采集的数据项,或提供被检工件照片与精度要求,敏洽可先给出可行性判断与硬件前置条件,再谈软件工作量与报价。