一家机构觉得自己的测评流程特殊，可能是项目叫法、人员分工与别家不同，也可能确实存在现有软件无法承接的业务规则。两种情况需要的投入差别很大。
决定是否开发前，先挑出一条最不能妥协的要求，写清楚谁在什么条件下做什么、系统必须留下什么结果，再用现有软件验证。能够通过配置完成，就没有必要为这条要求重建系统；确实做不到，再判断缺口值得局部开发，还是已经影响整个系统的选择。
“我们一直这样做”，还需要追问一步
判断一项要求是否必须保留，可以问：换一种做法，会损失什么？
例如，机构习惯把测评批次叫作“服务期”，把参与者叫作“项目成员”。如果换一个名称不影响任务归属、执行和查找，可以先核对软件中的项目组织方式，不必立即要求开发专属模块。报表列顺序、页面布局和操作入口，也适合先比较调整习惯与修改软件各自的代价。
但有些要求不能靠换个名字解决：项目助理需要知道谁尚未完成，却不应看到个人测评结果；第二阶段必须等指定人员确认后才能启动；同一参与者进入不同项目后，历史记录的归属和可见范围必须保持明确。这些要求改变了信息如何流转、谁能做决定，值得作为选型的必验项。
一个实用做法是给每条要求补上理由：“必须保留，因为省略后会导致……”如果后半句只能写出“不习惯”，先讨论是否调整做法；如果会造成错发任务、越权查看或记录混淆，就要验证系统能否守住这条规则。
把一段特殊流程拆开，才能看见真正的缺口
假设一家机构开展分阶段测评：工作人员组织第一轮测评，专员复核后安排后续任务，项目负责人按服务期查看进度。机构认为必须开发一套自己的系统。
先把这段话拆成三件事：
- 组织与命名。 “按服务期查看”具体是需要更换名称、按批次筛选，还是要求一个人同时归属多个项目？前两项可以先查现有组织方式；最后一项要进一步验证人员和项目的关联规则
- 阶段流转。 “复核后安排”是专员确认完再手动发起下一轮，还是系统必须阻止未获批准的人进入下一阶段？如果要求强制控制，就不能用工作人员口头承诺“我们会注意”代替
- 数据可见范围。 助理催办是否只需要名单和完成状态？专员可看哪些个人记录？项目负责人看汇总还是明细？把各自需要看到和不能看到的内容分别列出，才能核对权限是否满足要求
拆开后，可能发现只有“确认后才能进入下一阶段”存在缺口。此时值得评估的是这段流程如何实现，而不是默认把答题、计分、报告和项目组织全部重做。
反过来，如果现有产品无法表达机构最基本的人员归属与服务阶段，导致每一次操作都要人工改表、重新匹配记录，就不能只看页面上是否有几个相似按钮。
用自己的难例试跑，记录到底怎样完成
要求供应商演示时，可以带一组虚构的人员和项目数据，沿着上述流程走一遍。既看正常完成，也看一个关键例外：专员撤回了确认，尚未开始的后续任务应该怎样处理？这个例外是否重要，应由机构根据真实业务决定。
每个步骤都记录其实现方式，至少区分下面四种：
- 现成可用： 当前交付版本中能直接完成，实际操作与机构要求一致
- 配置后可用： 能在受支持的设置范围内完成，并说明谁来配置、配置是否另收费、升级后如何保留
- 需要人工补充： 写明由谁完成、每批要花多少时间、如何核对，以及人员缺席时谁接手
- 需要另外实现： 明确缺失的具体步骤；若涉及开发或对接，另列范围、费用、验收和维护责任
“可以实现”需要落到这四种结果之一。供应商未来可能开发的功能，也应与当前交付能力分开记录。
英国政府数字服务的技术采购指南建议在小规模试用中验证一个小而难的问题。对测评机构而言，最有价值的试跑，就是把最担心无法完成的那一步真正走通。
不要简单按功能数量算“满足率”。十项便利功能可以弥补操作体验，却未必能弥补一项必要的权限限制。先列必须通过的要求，再比较其余部分的效率和成本。
什么样的缺口，值得投入开发？
开发值得进入候选方案，通常需要几件事同时说得清楚：
这条规则确实重要，而且已经稳定。 机构知道它解决什么问题，也能给出正常情况与例外情况的处理办法。如果连业务负责人都还没有确定“谁来确认、何时算完成”，先整理流程会比立即写代码更有帮助。
现有方案的缺口已经验证。 比较过候选产品、配置方式和可接受的流程调整后，仍有必要规则无法满足。只看过一个演示、没有找到某个按钮，还不足以说明必须自研。
长期补救的代价值得替换。 例如每个项目都要重复匹配人员与阶段，且一旦错配就会影响后续任务。这时应记录实际工时、返工和延误，再与开发投入比较。偶尔发生、不会突破信息访问边界、又有明确负责人核对的附加工作，可以先保留人工处理。
有人持续负责。 机构需要能决定需求、参与验收、安排维护预算的人。即使由外包团队开发，也要有人判断交付是否正确，并在规则变化后组织修改。
比较费用时，让各方案完成同一组必要任务，再按机构计划使用的年限计算：购买方案要计入配置、实施及持续人工补充的成本；开发方案要计入需求梳理、测试、上线、维护和交接。不要拿完整采购方案的报价，与只包含初次编码的报价比较。保留以后调整方案的余地，也是GOV.UK 技术选型指导强调的原则。
如果只有一小段业务规则需要新实现，可以评估保留现有测评工具、单独补充该环节的可行性。这里要先确认数据如何衔接、谁负责核对、升级后谁维护；产品是否提供接口、能开放哪些数据，都需要实际核实。没有可靠衔接方式的两个工具，可能把开发成本变成长期人工搬运成本。
私有化部署，也要单独回答业务适配问题
如果机构的主要要求是指定运行环境，应把部署条件单列出来；如果主要要求是特殊的审批、任务或数据关系，再评估业务实现方式。两组问题分别确认，才能知道到底需要买什么、增加什么工作。
橙星云提供标准化 SaaS 服务，也支持私有化部署。评估时，可以拿机构最难的一段流程，逐项核对所选方案的实际支持范围。涉及定制开发、接口或源码交付的要求，需要另行确认并明确项目范围，不能仅凭“支持私有化部署”作推断。