第一次拜见分管校领导以后，学校安排了一位系主任的助理负责日常对接。接下来的那段时间，她带着我们在不同部门之间来回跑：合同从哪里产生，归哪个部门管，经过谁审批，最后又由谁用印、付款和归档，都要一处一处问出来。
我们没有指望某一位老师把整套需求一次讲完。高校里的合同分散在采购、科研、教学、后勤、合作办学、学生管理等业务中，每个部门掌握其中一段。一个部门说清楚自己的事情以后，往往还要去另一个部门确认它的前置条件或者后续处理。
为了让每次沟通都能留下可以继续整理的东西，我们给不同部门准备了不同的需求卡片。卡片上的主要内容不是大段填空，而是提前列好的合同名称、岗位、流程动作、业务字段和系统名称。校方老师负责勾选与本部门有关的内容，只有材料中没有出现的特殊情况，才需要在“其他”一栏补充。
这些卡片后来成为整个需求工作的起点。项目完成以后再看，最终采购需求材料中的74种合同、十类标准角色和五类外部系统，都能沿着当时的部门沟通重新找到来源。
第一张卡，先回答学校到底有哪些合同
我们首先要确认的不是审批页面长什么样，而是学校究竟要管理哪些合同。如果连合同范围都没有摸清楚，后面讨论模板、字段和流程，很容易只围绕几个常见的采购合同打转。
合同类型卡按照业务分组，把可能涉及的合同直接列在纸上。货物采购类有国内货物采购、进口货物采购、仪器设备、家具、图书和教材；服务采购类有信息化建设、设备维保、物业、餐饮、车辆、修缮、招标代理、法律顾问、工程造价和审计等；后面继续列工程、科研、合作、人事、后勤保障、信息化与数据、无形资产、租赁场地、学生管理以及校企社会合作。
卡片交到一个部门手里以后，对方只做两件事：勾选本部门实际接触的合同，再勾选自己承担什么职责。卡片的基本样式如下：
这张卡片的表头只记录四件事：哪个部门填写、由什么岗位填写、谁代表本部门确认，以及确认日期。真正需要老师处理的内容放在下面。我们把合同按照货物采购、服务采购、工程、科研、合作、人事、后勤保障、信息化与数据、无形资产、租赁与场地、学生管理、校企与社会合作等类别排好，再把材料中的74种合同逐一列出来。老师不用从空白纸上回忆合同名称，只需要顺着清单判断本部门有没有这种合同。
但是，只确认“有没有”还不够。科研横向合同可能由科研部门归口，却由二级学院发起；仪器设备采购合同可能由使用部门提出，采购部门负责招采审核，财务部门审核资金，最后还要有人验收、用印和归档。因此，每一种合同后面还跟着一组职责选项，让老师继续确认本部门是发起、部门审核、业务归口、招采审核、法务审核、财务审核、履约验收、用印归档，还是只需要查询。
这样，一张卡片收回来以后，我们得到的就不是一句“我们部门也有合同”，而是“这个部门涉及哪些合同，在每种合同里承担什么责任”。如果材料里的74种合同仍然没有覆盖实际业务，卡片最后才留一个“其他”填空，让老师补充合同名称。能勾选的尽量勾选，只有材料里确实没有答案的地方才让人填写，这才是这张卡片真正的设计原则。
正式卡片中不是上面展示的15种，而是后来汇总进入材料的全部74种。各部门分别勾完以后，我们才能把同一种合同放在一起看：谁发起，谁归口，谁只参与审核，谁负责合同签署后的履约。没有部门勾选的合同要确认是否删除，多个部门同时勾选“业务归口”的合同则要继续协调。
最终形成的《合同分类表》保留了74种合同及其归口部门。例如，仪器设备采购和教材采购归教务部门，图书采购归图书馆，工程施工和物业服务归总务后勤部门，科研横向合同归科产相关部门，继续教育合作与培训合同归继续教育相关部门。对系统来说，这张表决定分类目录和权限；对学校来说，它第一次把散落在不同部门的合同放进同一套管理范围。
合同管理和法务，确认的是规则，不是所有部门的操作
合同类型确定以后，合同管理和法务拿到的是另一张卡。他们不需要重新描述每类合同每天怎样发起，而是确认分类、模板、编号、审查和风险规则。
分类部分让对方勾选是否采用三级目录，是否区分采购与非采购、支出与收入，是否给每类合同配置归口部门和负责人，分类新增、编辑、停用是否需要审批。模板部分直接列出范本合同、非范本合同、多版本管理、模板审批发布、非标准条款偏离说明，以及合同与模板、审批表单、招标文件和投标文件的一致性核对。
模板怎么用，也不能只写一句“支持合同模板”。我们让合同管理和法务在三种方式中确认一种：某类合同是必须使用学校范本，还是推荐使用但允许改用非范本，或者完全不限制模板。选项后面对应的是三套不同的系统规则。强制使用范本意味着经办人不能随意上传另一份合同；允许使用非范本，就要继续确认偏离说明和法务审查；不限制模板，则不能再按范本使用率去要求业务部门。
编号规则采用相同的办法。年份、部门、合同分类、流水号和自定义字符都提前列好，由校方决定哪些部分需要组合。只有具体格式、部门编码以及流水号按年还是按月重置需要填写。看起来只是几个勾，最后却能直接落成编号规则：编号由什么组成、什么时候重新计数、作废编号能否再次使用，以及历史合同能不能手工补录。
只有具体格式、部门编码和流水号按年还是按月重置需要填写。风险审查同样拆成法律风险清单、高中低风险等级、标准修改建议、敏感词库、启用停用和审查报告等选项，由法务确认采用哪些，并提供现有风险点和Word合同模板。
这张卡最后不会直接变成一个页面。它会继续形成《合同分类配置确认单》《合同模板—书签映射表》《编号规则配置确认单》《法律风险清单配置确认单》和《敏感词库配置确认单》。学校负责确认业务内容，我们负责把确认结果配置到系统里。
十类角色放在一张卡上，先勾人，再排顺序
审批流程不能只问一句“你们现在谁审批”。同一个岗位在不同合同中可能出现，也可能因为合同类型和金额不同而改变顺序。因此，我们把材料中的十类标准角色直接列入流程卡：经办人、所在部门负责人、业务归口管理部门负责人、招标办负责人、合同管理岗、财务部负责人、合同管理部门负责人、分管校领导、校长和审计纪检人员。
各部门先从十类角色中勾出与自己有关的岗位，再确认这些岗位可以执行通过、退回、转办、加签、填写意见、批量审批和移动审批中的哪些动作。随后再判断什么情况会让流程发生变化：合同类型不同是否走不同归口部门，金额达到什么标准需要增加领导，采购合同是否必须经过招标部门，重大合同是否需要上会，使用非范本或者修改范本是否增加法务审查，命中高风险规则以后又由谁处理。这里仍然只有金额阈值和材料中没有出现的特殊条件需要补充填写。
材料中将审计纪检定义为独立监管角色，并不参加普通审批。因此，不能因为它需要查看全校合同和接收预警，就把它机械地塞进每一条审批链。角色卡解决的是“谁在系统里承担什么责任”，流程顺序则要按具体合同类型继续确认。
最后，我们把勾选结果整理成《角色及权限确认表》和《审批流程配置确认单》。这样系统配置的就不再是某位老师的姓名，而是一个岗位；人员发生变化时，只需要调整岗位任职人员，不需要重新修改整条流程。
采购卡片，把一句“对接采购系统”拆成可以确认的内容
到了采购与招标部门，卡片换成了采购项目和合同之间的数据关系。第一部分列出合同发起时可能从采购系统取得的内容：项目名称、项目编号、项目负责人、采购方式、采购组织形式、中标供应商、统一社会信用代码、中标金额、核心标的物、招投标文件、中标通知书和论证资料，由采购部门逐项勾选。
第二部分是合同签署后的回写内容，选项包括合同编号、合同金额、供应商信息和签署日期。第三部分则把合同与采购文件可能需要核对的内容全部摊开：供应商名称、统一社会信用代码、合同总金额、分项报价、交付期限、质保期、付款方式及比例、验收标准、知识产权归属和违约责任。采购部门先确认哪些字段必须一致，再与合同管理部门一起决定出现差异以后是填写说明、上传佐证材料，还是直接阻断合同继续提交。
核对出差异以后，卡片继续让采购和合同管理部门确认处理方式：是否逐项勾选一致或不一致，是否强制填写差异说明，是否上传佐证材料，供应商名称和合同总金额不一致时是否阻断。采购系统临时不可用时，则确认是否允许手工录入中标信息、上传中标通知书、标记为“待核验”，并在接口恢复后重新比对。
这张卡完成以后，“对接采购系统”才被拆成数据获取、数据回写、一致性核对和异常处理四部分。产品经理后面编写接口需求时，不需要凭经验猜采购部门究竟想要什么。
财务卡片，沿着预算、付款和收款往下走
财务部门拿到的卡片从合同发起前开始。经费卡、项目号、可用余额校验、余额不足阻断、审批通过后冻结经费，以及合同金额变更后调整冻结额度，都作为现成选项交给财务确认。
进入付款阶段，卡片列出付款申请需要携带的合同编号、供应商、付款金额和付款条件，也列出财务回写的支付状态、支付时间和凭证号。材料中明确提出合同、验收单和发票的三单匹配，以及无验收记录时阻断付款申请，这两项也放在卡片上直接勾选。
工程合同的款项被单独拆成预付款、进度款、结算款和质保金，再由财务与总务后勤共同确认每个节点需要关联什么验收或履约文件。这样做以后，财务规则不再只停留在“付款”两个字上，而是能落到具体节点和具体材料。
收入合同使用另一组选择。材料中列出的租金收入、培训费收入、科研合作收入和捐赠收入，分别交给相关部门确认；收款计划则勾选收款节点、金额、方式、到期提醒、到账确认、收款台账和统计。由此，支出合同和收入合同从分类阶段就被分开，后面不再拿付款流程硬套收款业务。
科研卡片，一头连合同，一头连科研项目
科研和科产相关部门先从合同类型卡中勾选科研纵向、科研横向、专利许可、专利转让、知识产权共享、仪器设备共享、产学研合作、联合实验室和成果转化等合同，再进入科研系统对接卡。对接卡上已经列好需要取得的项目信息：项目编号、项目名称、项目负责人、项目起止日期、经费总额和可用余额；合同签署以后，是否把合同编号、金额、合作方和合同起止日期回写科研系统，也由对方逐项确认。
材料中还包括科研经费冻结、中期检查、结题验收，以及论文、专利、软件著作权和报告等预期成果。把这些内容放进卡片以后，我们确认的不只是“科研合同走什么审批”，还包括合同履约怎样与科研项目进度发生关系。
用印、档案、信息化和审计，各自只确认自己掌握的部分
党政办公室、印章和档案岗位拿到的卡片，从公章、合同专用章、部门章和电子签章开始。是否审批通过后发起用印，是否填写用印份数和用途，是否按印章类型配置流程，是否记录用印人和审批人，是否用印完成后才能备案，以及是否固化最终合同版本，都由对应岗位勾选。备案部分再确认盖章扫描件、验收单、补充协议、备案证明、卷宗目录、材料完整性校验和超期提醒。
信息化部门确认的是五类外部系统：统一身份认证、招标采购、财务、科研和OA或钉钉。单点登录、教职工信息、部门组织、审批待办、移动跳转、合同数据回写和附件预览，需要哪些就勾哪些；接口中断后，合同起草、审批、用印、备案、查询和移动审批哪些必须继续运行，也由他们确认。异常日志、告警、自动重试和手工补录，则决定接口出问题以后由谁发现、怎样补救。
审计纪检卡片列的是材料中的风险和追溯内容。供应商黑名单、合同金额异常、合同倒签、预算超支、实质性条款变更、无验收付款、超期未履约、归档缺失和预算偏差，哪些需要监督直接勾选；审批、版本、用印、履约、付款、变更和数据操作记录，哪些需要查询也逐项确认。审计整改状态则统一为待整改、整改中、已整改、已验收和超期未整改。
校领导和项目负责人不替这些部门重新回答业务问题。他们拿到的是范围确认卡，用来确认本期是否覆盖起草、审批、签署、用印、备案、履约、变更、续签、归档、纠纷、审计整改、供应商风险、重大合同上会、移动审批和历史数据迁移，以及跨部门冲突最终由谁决定。
卡片收回来，产品经理才开始做真正的整理
在校内助理的带领下，我们把这些卡片带到对应部门，再根据勾选结果逐项核对。一个部门勾选的内容，先回到它提供的合同、制度和表格中验证；多个部门对同一个选项作出不同选择的，单独进入待确认问题；所有“其他”项，则补充进原始合同类型或业务规则清单。
卡片回收后，我们形成了五类中间成果：《合同类型与归口确认表》记录74种合同分别由谁发起和归口；《角色及权限确认表》记录十类角色能看什么、能做什么；《审批流程配置确认单》记录不同合同使用的角色和顺序；《系统接口与数据交换清单》记录五类外部系统的数据来源、流向和异常处理；《待确认及待决策事项表》则专门存放跨部门冲突。这些文档还不是最终需求书，却已经把散落的部门意见变成了可以继续加工的原料。以后某条需求发生争议，我们能够回到对应卡片，找到勾选部门、确认岗位和支撑材料，而不是只剩一句“学校当时说过”。
第一篇里，那位助理带着我们敲开了不同部门的门。第二篇里，我们靠一张张卡片，把每扇门后面的合同、岗位、流程和系统带了回来。卡片上大多数只是一个勾，但这些勾连在一起，才逐渐拼出了这所学校的合同管理全貌。
产品经理不是替学校写答案，而是先把问题变成学校能够准确确认的答案。
下一篇，我会继续写这些卡片收回来以后，我们怎样把勾选项、部门意见和现有材料整理成业务规则，再转换成可以交给学校确认的正式需求文档。
后附资料：《高校合同系统需求调研勾选卡》。正文负责讲清楚我们为什么这样问、分别问了什么以及怎样形成成果；完整表格单独作为可复用的调研附件提供。
