最近公司要求IT部分参与软件选型采购的前期评审。在讨论到技术规范时，出来了一些问题。技术规范到底写到什么程度？哪些内容让供应商应答？接口和费用边界怎么说？供应商方案和甲方要求怎么区分？这类问题在甲方 IT 里很常见。很多软件采购，看起来是在比价格，实际前面的需求边界、接口责任、验收口径还没讲清楚。

我现在更倾向于先做一件事：在正式询价和评审前，IT (或企业里的需求部门)先把技术规范写清楚。技术规范的作用，更多是把口头需求变成供应商能响应、采购能比较、合同能引用的边界文件。

一、甲方写技术规范，乙方写技术方案

软件选型时，甲方和乙方要各自把自己的事情讲清楚。甲方技术规范主要回答：我们要解决什么问题，本期做到什么范围，涉及哪些系统、接口、安全、权限、费用和验收要求。供应商技术方案主要回答：你怎么实现，哪些是标准功能，哪些要开发，需要甲方和第三方怎么配合，费用和周期怎么算。这两个东西一混，后面就容易扯皮。甲方只写“支持集成”“满足安全要求”“支持统一门户”，供应商通常都会答复支持。但支持也分很多情况。标准功能可以叫支持，二次开发也可以叫支持，只提供接口文档也可以叫支持，需要第三方系统配合改造也可以叫支持。所以技术规范不能只写方向，要写到供应商可以逐条应答。是否满足。怎么满足。是否标准功能。是否额外收费。需要谁配合。这些问题写清楚，后续报价才有比较基础。

二、软件采购先判断类型

不同软件采购，技术规范不用写成一个样子。我通常先做一个简单分类。

这篇文章重点讲第一类。因为这类项目最常见，也最容易被误认为“需求已经很清楚”。比如统一身份认证。大家都知道要做账号统一、单点登录、权限集成。但真正到采购前，还要把系统范围、账号和组织来源、协议支持情况、接口开发责任、后续新增系统接入费用这些内容讲清楚。这些内容采购部门很难替 IT 判断。采购能管流程、比价、合同流转和商务谈判。技术边界需要 IT 牵头。

三、IT 前期重点抓四个边界

需求明确的软件项目，IT 前期不用把方案替供应商写完。但要把甲方边界讲清楚。

这里面最容易出问题的是费用边界。很多软件采购前期只看总价。但软件价格背后，经常还包括授权、实施、接口、开发、培训、维保、扩容和第三方配合。总价低，不代表后续总成本低。总价高，也不代表一定不合理。关键要看它包含了什么，没包含什么，后续变化怎么计价。所以不要提前替供应商设计收费项。先让供应商报完整方案。再看总价。再拆明细。再识别不合理拆项。这个顺序很重要。

四、供应商可以沟通，判断权要留在甲方

供应商预沟通有价值。他们知道产品能力、类似项目风险和市场价格，也知道哪些需求后面容易变成坑。但甲方不能让供应商替自己定义需求。可以问供应商哪些是标准功能、哪些要开发、接口怎么做、授权和维保怎么收费、后续扩容怎么计价。不适合提前透露内部预算、倾向供应商、其他报价、内部估算人天和评审重点。软件采购到了议价阶段，IT 也不能缺席。价格表面是商务问题，背后经常是技术边界问题。不同供应商报价差异很大，可能不是单纯价格高低。可能是范围理解不同，接口责任不同，授权口径不同，实施深度不同，也可能是有人先低价进场，把风险留到合同之后。这些差异，采购很难单独判断。IT 要把技术差异讲清楚，采购再去谈商务条件。

结尾

软件采购看起来是采购流程。实际背后有业务流程、系统接口、数据边界、账号权限、安全要求和长期运维成本。采购部门可以帮助完成流程和商务谈判。IT 要负责把技术边界讲清楚。对于需求比较明确的软件项目，技术规范至少要做到三件事。把业务目标转成供应商能响应的要求。把范围、接口、费用和验收边界提前说清。把供应商承诺变成后续合同和验收依据。技术规范写清楚，软件采购才有谈判基础。边界提前说清，项目后面才少扯皮。