BUY OR BUILD / INVENTORY
库存系统选型：定制开发、现成软件，还是混合方案？
软件演示都说支持入库、出库和多仓。真正影响选择的，往往是部分发货、在途调拨或退货这些细节。把候选方案放到同一笔业务里试，再比较成本与交接。
本页内容
先拿最难的一笔业务来比较。
把最难处理的几笔业务拿给候选产品试：部分发货、跨仓调拨、退货或一批货被多个订单占用。如果配置后能顺利完成，就没有必要为了“定制”而重做；如果关键步骤仍得靠另一张表补，才需要认真评估接口或开发。
三种路径，各自解决什么？
左右滑动，查看完整表格。
| 判断维度 | 现成产品 | 定制或混合 |
|---|---|---|
| 流程适配 | 先验证配置能否覆盖关键例外 | 围绕特定规则开发或补齐缺口 |
| 持续成本 | 订阅、用户、扩展模块、接口及服务费 | 开发、基础设施、维护与后续变更 |
| 数据迁移 | 核对导入、导出与关联记录限制 | 自行定义映射、对账与回退责任 |
| 控制与交接 | 按厂商合同确认访问与退出条件 | 约定源码、部署、许可及维护责任 |
让候选方案处理同一笔业务
准备一笔采购、一笔部分发货、一次退货和一条批次追溯。分别检查预占、单位换算、取消、审批和多仓数量。让未来的操作人员实际完成任务，记录需要人工补表的地方。
混合方案也要测试接口失败：谁是库存事实来源，重复同步会不会产生两笔移动，离线订单如何补记？如果职责不清，两个系统可能比一个表格更难对账。
演示时，“支持多仓”这个答案还不够。可以继续问：仓库 A 向仓库 B 调拨，货已离开 A、B 还没签收时，各自显示多少？运输中丢失一件，由谁调整？把这种问题写下来，让候选产品和定制方案分别实际处理，才知道差异是在配置、流程还是底层数据模型。
要请真正操作的人参与，而不只让采购负责人看演示。仓库人员可能关心连续扫描是否总要重新选择库位，财务人员关心撤销后能否找到原单。这些细节会影响每天的使用，功能名称相同并不意味着体验相同。
比较完整使用成本，不只比较首付款
把相同的使用周期、用户数量、仓库规模、接口和支持需求放在一起。现成产品可能需要额外配置、插件和数据整理；定制项目也有部署、维护、升级和变更成本。没有范围资料，不宜给出“定制一定更便宜”的结论。
查看软件预算的工作包拆分方法退出方式也值得试。请对方实际导出一小批带批次、附件和关联单据的数据，看看导出后还能不能解释一笔库存变化。拿到一份余额 CSV，并不意味着拿到了能在下一套系统中继续使用的业务记录。定制项目同样要在交接前演练这一点。
示例：保留 ERP，只补齐现场操作
假设 ERP 已能管理财务与物料，但现场领料仍靠纸张。可先评估扫描工作台与既有接口，而不是重写 ERP。验证领料单、重复扫描、退料、网络中断和每日对账；若接口不可用或无法表达批次规则，再重新评估边界。此例用于解释选型方法，不对应客户交付或收益。
作出决定前，问这五个问题
- 哪三条规则不满足就不能上线？
- 现成产品能否现场演示这些例外？
- 谁负责数据清洗、接口与对账？
- 退出时能取得哪些数据和资料？
- 哪个最小流程足以验证选择？
一起判断选型边界
先描述当前做法、最困扰的一步和希望得到的结果。无需完整需求文档，敏感资料可在保密协议后提供。
讨论我的项目