立一个自动化立体库，甲方要做的一个关键决策是：整体打包给一家供应商，还是硬件与软件分开招标、由不同供应商实施？
多数项目选了前者，理由也实在：一家总包，责任单一、协调简单、不用自己懂那么多。这个选择在项目上线时通常看不出问题，代价出现在三五年后 —— 想加一条输送线、想把堆垛机换成别的品牌、想上一个新业务场景时才发现：你没有改的权利，也没有议价的能力。
本文只讨论这一件事，按五步说清楚：一体化总包的代价是怎么产生的 → 分开实施换回什么 → 什么情况下反而不该分标 → 分标需要哪些前提 → 甲方该怎么划标段、写条款。
一、一体化总包的代价，是怎么产生的
代价一：接口层失控——私有协议 + 残缺文档
总包方既做硬件又做软件时，软件与设备之间的对接往往采用"内部约定"：只有他们自己清楚的私有报文、私有状态码、私有调用时序。这套东西不在任何公开标准里，甲方也无法验证其合理性。
更常见的是另一种情况：协议本身用的还是西门子 S7、Modbus TCP 这类标准协议，但文档不交付，或者只交付残缺版本 —— 点表不全、报文格式只有片段、状态码含义靠口头传授、异常码靠现场猜。知识沉淀在实施人员脑子里，随着人员流动而流失。
两条路的结果一样，接口层失去管控能力：
- 想改一个字段、加一个信号，必须等对方排期，自己改不了；
- 出了故障双方各说各话 —— 你说软件没发对，他说设备没回对，拿不出中立的判断依据；
- 想引入第二家设备做比价，发现新设备根本接不进这套私有协议；
- 换任何第三方来维护都要重新摸索一遍，成本接近重做。
接口的本质是边界的契约。契约如果是单方书写且不公开的，它就不是契约，是依附关系。
代价二：升级改造只能回头找原厂，没有第二个选项
接口一旦失控，后续所有动作都被锁死在同一家供应商身上：
| 场景 | 一体化总包模式下 | 直接后果 |
|---|---|---|
| 产能扩容 | 只能沿用原品牌设备与原软件 | 报价缺乏市场参照，无从比价 |
| 新增业务场景 | 需求提给原厂，排期与报价由对方定 | 响应慢、成本高、无法并行招标 |
| 原厂服务终止 | 文档不全、接口封闭 | 系统进入运维僵局，改造等于重做 |
| 引入新供应商 | 接口不开放，无法对接 | 被事实性锁定 |
这里的关键不是某家供应商"恶意抬价"，而是结构上你没有第二个选项。没有选项就没有议价权 —— 这是工程决策带来的商业后果。
代价三：软件不是硬件团队的主业
硬件团队擅长的是设备：机械精度、电控逻辑、节拍与可靠性。软件对他们而言是配套项，这带来两个先天短板：
- 没有可复用的底层框架：往往按项目从零写一套，A 项目的经验难以沉淀到 B 项目。同一个"储位锁定"逻辑，在三个项目里可能是三份互不相干的实现，缺陷也跟着复制三遍。
- 行业业务理解靠临时补课：电力计量器具的全生命周期台账、检定配送协同、多级库房调拨；烟草的批次追溯；SMT 的湿敏与效期 —— 这些不是通用功能清单里能勾出来的，需要长期在行业里积累。
表现就是：演示时功能都有，上线后异常场景处理不了。因为异常分支才是仓储软件的主体工作量，而它只能靠经验积累。
二、分开实施换回来的是什么
| 维度 | 一体化总包 | 软硬件分开实施 |
|---|---|---|
| 接口协议 | 私有约定，甲方无法管控 | 标准协议（S7 / Modbus / OPC UA / EtherCAT 等）+ 适配层，接口开放可验证 |
| 接口文档 | 内部消化，文档残缺 | 完整接口文档、点表与报文说明作为交付物 |
| 升级扩容 | 只能找原厂，议价困难 | 软硬分离，可换设备品牌、可多方比价、可自主扩展 |
| 软件产品力 | 按项目从零开发 | 成熟 WMS 底层模板与框架，行业能力可复用 |
| 业务理解 | 需临时补课 | 行业场景沉淀，异常分支有既有处理策略 |
| 长期演进 | 受制于原厂产品路线 | 按客户业务节奏迭代，数据与资产归客户 |
表里真正值钱的不是前两行，而是第三行之后的长期自由度。它靠两条机制落地，缺一条就是空话。
机制一：适配层解耦。专业的软件方会把协议适配与调度引擎分开：调度引擎只关心"下发什么任务、期望什么结果"，报文怎么组、数据怎么解析由适配层承担。新增一个品牌设备只需开发一个适配器 —— 把西门子换成别的品牌是换配置项，调度逻辑不用改。接口从"黑盒"变成"可替换的插件"，管控权自然回到甲方手里。
机制二：交付物写进合同。接口文档、点表、报文样例、部署手册、源码或源码托管方式、数据资产归属，在合同阶段明文约定。知识不沉淀在某个工程师脑子里，而是沉淀在交付物里。这一条决定了三年后你有没有"自己找人维护"的自由。
至于议价权：它不是谈出来的，是架构给出来的。软件不绑定硬件品牌，设备层可按性价比选型；扩容时先比设备价，再谈软件适配工作量；原厂服务终止，也有迁移路径而不是从头再来。
三、什么情况下，其实不该分标
分开实施不是无条件更优。下面三种情况，一体化总包反而更合适：
- 规模小、设备单一：几百个托盘位、只用堆垛机的小型库，接口复杂度有限，分标带来的协调成本很可能大于收益。
- 甲方无力承担协调角色：没有自己的项目经理、也不愿请第三方监理，两家供应商之间就没有裁决人。这时分标的风险高于被锁定的风险。
- 工期极紧、要求快速上线：分标需要前置的接口责任矩阵与联调计划，这些工作量省不掉。时间不够时硬分，很容易变成现场扯皮。
一句话概括：分标买的是长期自由度，付的是短期协调成本。立库通常要用十年以上，多数场景下这笔交换划算；但如果这套系统本来就不打算长期演进，就不必为这个概念多付成本。
四、分开实施的四个前提
做不到这四条，分标会变成互相推诿的灾难 —— 它们不是建议，是前置条件。
- 接口责任矩阵前置：每一台设备、每一个对接系统，写明谁提供接口、谁负责联调、数据口径由谁确认、异常由谁兜底。这份矩阵应在招标阶段形成，而不是联调时才吵。
- 明确总体协调方：甲方要指定一个总牵头（自己的项目经理，或第三方监理），负责里程碑、联调排期与争议裁决。两家供应商之间不存在天然的协作义务。
- 联调计划写进合同：单机调试 → 联动调试 → 压力测试 → 异常演练（断网、设备故障、任务超时），每个阶段有明确的入口与出口条件，以及未通过时的责任归属。
- 软件方必须有硬件对接经验：只会写业务系统的团队接不住设备层。选型时要看它实际接过哪些品牌、哪些协议，而不是听它说"都能接"。
五、甲方怎么分标
标段怎么划
- 硬件标段：货架、堆垛机 / 穿梭车、输送线、提升机、AGV、扫码与称重设备，含电控与安装调试；
- 软件标段：WMS 仓储管理、WCS 设备控制（或 RCS 机器人调度）、数字孪生与看板，含接口开发与联调；
- 明确交叉项：网络与服务器、PDA 与标签、上位机接口，写清楚归属，避免两不管。
招标文件里必须写进去的条款
- 设备通信采用标准协议（明确列出 S7 / Modbus TCP / OPC UA 等），不接受私有封闭协议作为唯一对接方式；
- 硬件方须提供完整点表、报文格式与状态码说明，作为验收附件；
- 软件方须开放接口文档，源码或源码托管方式、数据资产归属写入合同；
- POC 用甲方真实单据跑完整流程，不是看标准 Demo；
- 验收标准包含异常演练与回退预案，而非仅功能清单勾选。
六、常见疑问
Q：分开后出问题，两家会不会互相推诿？
会 —— 如果没有接口责任矩阵和总体协调方。所以第四章那两条前提是分标能否成功的关键，不是可选项。
Q：分两个标是不是更贵？
一次性采购成本未必更高（硬件可以比价、软件不必付"总包管理费"），真正的差别在全生命周期成本：后续扩容、改造、换设备时有没有第二个选项，差距往往是数量级的。
Q：已经是一体化系统了，还能拆吗？
能，但要看接口现状。如果协议与文档都封闭，通常的做法是先在现有系统旁并行部署新软件、双模式运行验证，稳定后再切换。关键是先把"接口能拿到什么"摸清楚。
小结
软硬件分开招标实施，表面上增加了一个标段和一份协调工作，实质上买回来三样东西：可管控的接口、可验证的文档、可持续的议价权。这三样决定了这套立库在未来十年是资产还是包袱。
验收标准也该跟着改：别定在"演示那天好不好看"，要定在"三年后我想改的时候，能不能改得动"。
最后一点边界：分开招标解决的是结构与权利问题 —— 接口能不能管控、文档拿不拿得到、换供应商有没有路。它不替你解决实施质量问题。主数据治理、期初盘点、切换并行期、异常分支这些，见《自动化立库 WMS 详解》与《电力计量库房自动化改造的六个要点》。