先给结论
- 评估的对象是「产品」不是「项目」：一个产品对应一份权属基础、一份检测报告、一张证书，与合同数量无关。
- SaaS 与同源的私有化部署，通常是同一个产品的两种交付方式；小程序要看后台是不是同一个。
- 定制开发能不能算产品，取决于有没有形成可复用的产品形态——每单重写的，很难界定为一个产品。
- 拆还是合，按顺序过三条判据：独立软著 → 功能边界可独立描述 → 是否单独定价销售。
问「我能报几个软件产品」的人，十个里有八个是从「我今年做了多少项目」起算的。这个起点就错了。
软件产品评估的对象是一个可以独立描述、独立检测、独立命名的软件产品。它的存在证据是软著、合格检测报告和功能说明，不是合同份数。给三家客户各部署一套进销存、代码同源只是配置不同——这是一个产品的三个部署实例，不是三个产品。反过来，同一家公司做的仓储管理和运输调度，功能边界清楚、各有软著、分别报价——这是两个产品。
这篇讲的就是这条线画在哪。产品评估的材料清单、检测机构资质、命名规范，材料那篇已经逐项讲过，本文不重复清单，只解决「边界」这一个问题。
一、评估的对象是「产品」不是「项目」：这一条决定了你能报几个
为什么强调「产品」这个词？因为产品评估的每一项材料，都是围绕「产品」而不是「项目」组织的：软著登记的是软件作品，检测报告测的是软件的功能与质量特性（依据 GB/T 25000.51），产品证书登记的是一个带版本号的产品名称。这三样东西都没有「第几个客户」这个字段。
所以判断顺序应该是：先把它抽象成一个产品，再看这个产品能不能成立；而不是先把项目列出来，再给每个项目配一套材料。后一种做法最常见的结局是：材料交上去，被认定为「同一产品的多个实例」要求合并，前面按项目做的检测白做。
这里还有一层业务含义值得说清：一个企业有没有「产品」，不只影响双软。定制开发的收入在高企的「高新技术产品收入」里也难认定，产品化程度会同时改变两张申报账——站内另一篇算过产品化程度怎么改手里的申报账，逻辑是同一个。
二、四种常见形态怎么判：纯软件、嵌入式、SaaS、小程序
把市面上的交付形态归成四类，判断会快很多。先给一张对照表，再逐类说关键处。
| 形态 | 通常怎么算 | 关键判据 |
|---|---|---|
| 纯软件（本地安装） | 一个产品 | 独立软著 ＋ 可独立描述的功能边界 |
| 嵌入式软件 | 一个产品，但销售额要从设备价款里拆出来 | 硬件厂把软件单独作为产品申报（另有专文） |
| SaaS | 与同源的私有化版本算同一个产品 | 功能边界一致、代码同源，只是交付与收费方式不同 |
| 小程序 / 多端 | 看后台是不是同一个 | 同一后台的不同客户端算同一产品；独立后台算不同产品 |
| 定制开发 | 看是否已产品化 | 标准功能＋配置＝可算；每单重写＝难以界定 |
SaaS 与私有化部署是同一个产品的两种交付方式
这一条最常被搞反。很多公司把「云端版」和「私有化版」分成两个产品去报，理由是「定价不一样、客户群不一样」。但评估看的是产品本身：功能边界一样、代码同源、只是部署位置和收费模式（订阅 vs 买断）不同——这属于同一个产品的两种交付方式，报一个是对的。报两个反而会在功能说明和检测报告上出现大面积重复，且很难解释「为什么两个产品测出来一模一样」。
但有一个例外要认得出来：如果私有化版本做了大量定制——独立分支、独立功能集、只服务特定行业——那它事实上已经是另一个产品，应当单独评估。判据很简单：能不能用同一份功能说明、同一份检测报告覆盖。能，就是一个；不能，就是两个。
小程序的判据同理，问的是「后台」：同一个后台的不同客户端（PC 端、移动端、小程序端）通常算同一个产品；独立后台、独立功能集的，算不同产品。这一条在实务中弹性较大，遇到边界情形建议申报前与受理机构确认，不要按表格硬套。
三、定制开发算不算产品：取决于有没有可复用的产品形态
这是问得最多的一类，也是最容易被情绪影响判断的一类——「明明是我一行行写出来的，凭什么不算产品？」
判断不看「是不是给客户做的」，看「有没有形成可复用的产品形态」。三个信号说明它已经产品化：①有标准功能集，客户差异靠配置而不是改代码；②同一套东西能交付给第二个客户而不重写核心；③有版本号、有产品说明、有对外统一报价。
反过来，如果每个客户的需求都靠改代码满足、没有共同内核，那它是一组定制项目。勉强报产品，会在检测环节露馅：检测机构按 GB/T 25000.51 测的是产品的功能性与质量特性，一份边界说不清的「产品」，测出来的报告也很难支撑评估。
四、一个产品还是多个产品：拆分与合并的三条判据
系列产品怎么拆才不会被要求合并
三条判据要按顺序过，前一条不过就不要再往后想：
① 有没有独立软著。软著是产品存在的权属基础。没有独立软著的「子产品」，通常会被视为母产品的一个模块——因为它在法律上不是一个独立的软件作品。
② 功能边界能不能独立描述。能用一段话讲清「它单独解决什么问题、明确不包含什么」，才算独立；讲不清就是模块。这一条比软著更本质：有些企业为了拆分特意补了软著，但功能说明写出来还是「某系统的一个子系统」，照样会被合并。
③ 是否单独定价销售。有独立报价、独立合同、独立发票的，拆分更站得住；只能打包卖的，合并更稳。因为「单独销售」是市场上对「这是一个独立产品」的投票。
三条都满足就拆，只满足一两条就倾向合并。拆得太细的风险是被要求合并、检测和材料白做；合得太粗的风险是功能说明写不下、检测范围过大导致报告不能反映真实产品。
五、命名与版本：判定的结果最终要落到证书名上
上面所有判断，最后都要收敛成一个名字。命名的通行结构是「品牌（或企业简称）＋ 产品名称 ＋ 软件 ＋ 版本号」，产品名称里不建议出现「平台」「系统」「云」「解决方案」这类泛词——它们无法界定产品边界，是要求改名的高发区。
版本号尤其要注意：它要在软著证书、检测报告、产品说明、销售合同与发票上保持一致。判定的结果如果是「两个产品」，就该有两套各自一致的名称与版本号；如果是「一个产品」，就只该有一套。名字对不上，前面判得再准也过不了形式审查。
顺带说一句嵌入式：硬件厂这条路的特殊之处不在「算几个产品」，而在「软件销售额怎么从设备价款里拆出来」——嵌入式软件那篇专门讲了这个拆分，本文不展开。
产品边界的判断没有标准答案表，但有稳定的思考顺序：先问「它是一个可独立描述的产品吗」，再问「它有独立的权属基础吗」，最后问「它值得单独占一张证书吗」。三问过完，报一个还是报几个，答案基本就出来了。
本文依据《软件产品评估标准》T/SIA 003-2019 与 GB/T 25000.51 整理，仅作政策机制解读；产品边界的具体判定、SaaS 与多端形态是否合并评估，以苏州市软件行业协会当期受理口径为准。
