谈判平台的数据就绪性：最低、实用、可选

实施团队通常预期的要少得多，真正必需的谈判平台数据其实并不多。在正式上线之前，组织需要的是受治理的记录：能够识别参与方、定义货物或服务、建立商务和流程规则、采集可比响应，并将拟议决策路由给有授权的人员。它并不需要一个完整的采购数据湖。

历史价格、供应商绩效、风险指标、预测、基准以及非结构化沟通内容，都可以提升采购谈判效果。它们属于实用或可选项——并非普遍适用的前置条件。因此，AI谈判数据就绪性的实际问题不是“我们的所有数据都齐了吗？”，而是“我们能否在可追责的人类控制下，准确、一致地执行这项工作流？”

快速回答

一个谈判平台至少需要：可靠的供应商身份信息、清晰的范围和行项目数据、单位、币种、日期、商务规则、评估标准、审批角色以及审计元数据。历史支出、绩效、风险和合同数据可以提升决策质量。外部数据源、转录文本、情感分析和AI推导预测属于可选项，只有在其来源和决策价值可以被证明时才应加入。

M-U-O 数据分层模型

使用 M-U-O 模型——最低（Minimum）、实用（Useful）、可选（Optional）——根据谈判平台数据所支持的能力来分类，而不是根据它恰好存放的位置来分类。

这种分类取决于具体情境。货运指数在办公用品事件中可能是可选项，但在物流谈判中可能是实用项。制裁筛查或必需认证在某个组织的政策或适用规则下，可能属于最低数据，即使它并不是每个事件都普遍需要的。

治理原则

只有当没有某个字段，工作流就无法安全运行或无法符合政策要求时，才应将其提升为 最低。当它能改变评估质量或谈判筹码时，应提升为 实用。当其价值只是看似合理但尚未被证明，或者治理成本可能超过决策价值时，应保留为 可选。

最低数据：正式事件前必须准备好的内容

最低并不意味着“现有的都算”。它意味着支持一个可理解的事件、可比响应和授权结果所需的最小受控数据集。

1. 目的、归属与流程

记录：

• 唯一谈判ID、标题和已批准的事件类型
• 预期结果，例如信息收集、采购订单、框架协议或合同
• 采购实体、业务单元、品类负责人和事件负责人
• 开始、澄清、截止和预期决策日期
• 审批路径和适用的权限阈值
• 当前事件状态和可审计的变更历史

这些治理信息是谈判记录的一部分，而不是实施过程中的额外负担。例如，Oracle 当前的供应商谈判文档将业务单元、日期、币种、评分、可见性、排名和响应控制描述为谈判级信息（source）。

2. 供应商身份

对于每个受邀方，保留：

• 唯一供应商ID
• 法律实体名称，而不只是交易名称
• 相关站点、地点或运营实体
• 授权联系人和沟通渠道
• 邀请和参与状态
• 必需的资格或准入状态

在谈判平台、ERP、合同库和供应商管理系统之间保留一致的标识符。重复或不匹配的供应商记录，可能会把报价、绩效历史或风险结果关联到错误实体。SAP 的供应商导入指南展示了在创建或对账记录时，如何实际使用 ERP 和供应商管理中的供应商ID（source）。

3. 范围与谈判行项目

每个行项目或标段应说明：

• 清晰的物料或服务描述
• 可用时的品类和物料编码
• 数量或预估需求
• 计量单位
• 交付地点和履约期间
• 技术要求和强制服务水平
• 标段与行项目之间的关系
• 替代品、备选方案和部分投标的规则

这些字段决定了报价是否可比。Oracle 文档将描述、品类和计量单位列为必需的行项目字段，并规定标准采购订单结果下数量也是必填项（source）。这是当前某种企业寻源设计的证据，并非普遍适用的法律要求。

4. 商务基础

定义：

• 谈判币种和允许的响应币种
• 汇率来源或换算方法
• 价格基础：单价、固定费用、费率卡、里程碑或总价
• 运费、税费、关税和其他成本要素的处理方式
• 付款、交付和责任转移条款
• 合同期限和需求假设
• 最低承诺（如有）
• 必需的合同条款

商务条款可能使表面上相似的价格产生实质差异。Oracle 的文档在谈判条款中涵盖了付款条件、运输、运费、责任转移、币种和换算汇率（source）。

5. 评估规则与权限

在发布前，批准以下内容：

• 强制性的通过/不通过要求
• 评分标准及权重
• 价格和总成本公式
• 非价格因素的处理方式
• 修订、逾期响应和备选报价规则
• 响应可见性和排名设置
• 利益冲突声明
• 授标和例外流程

权重和公式编码了政策判断。它们不应在未说明的情况下从旧事件中推断出来，也不应在收到报价后未经授权和记录就被更改。

6. 技术治理

每个重要字段都应具备：

• 来源系统和指定的记录系统
• 定义、格式，以及适用时的受控代码表
• 负责的所有者或数据管理员
• 创建、修改和批准时间戳
• 基于角色的访问控制和职责分离
• 变更历史
• 保留和删除规则

对于AI谈判，来源追溯尤其重要。NIST 的生成式AI概况建议保留相关第三方变更的来源、时间戳和元数据，并在供应商评估中纳入隐私、安全、知识产权及相关风险（source）。

实用数据：哪些内容能提升筹码和授标质量

当最低层已经运转后，实用数据会为评估人员提供背景：

• 历史数量、支出、投标和单价
• 当前合同、续约日期和终止条款
• 之前的谈判轮次、让步和授标
• 供应商交付、质量、服务和争议绩效
• 需求预测和量级情景
• 现有供应商地位和有记录的切换成本
• 材料、人工、物流、关税和间接成本因素
• 资质和供应商风险信息
• 可用替代方案和替代产品
• 已批准的目标、预算和底线区间
• 相关市场指数和基准
• 过往授标绩效，包括预期结果是否真正实现

供应商层面的问题还可以采集所有权、认证、环境实践、过往绩效、人员资质和财务可见性；Oracle 将这些列为谈判要求示例（source）。在完成所需验证之前，应将供应商回答视为声明，而不是事实。

比较前先标准化

历史价格并不自动构成基线。检查以下维度是否一致：

• 规格和质量等级
• 数量和量级承诺
• 计量单位
• 币种和生效日期
• 地理区域和交付地点
• 运费、关税和税务处理
• 付款条款
• 合同期限
• 风险分配和服务义务

只要这些维度中有任何变化，“上次支付价格”就可能制造虚假的确定感。

可选数据：仅在服务于明确决策时加入

可选输入可能包括：

• 应有成本或清单式成本模型
• 大宗商品、运费、人工或汇率数据源
• 供应商产能和网络信号
• 可持续性、排放或多元化属性
• 诉讼、专利或负面媒体信息
• 电子邮件、转录文本和会议纪要档案
• 关系或情感指标
• AI生成的目标、让步路径或供应商响应预测
• 匿名化的跨事件基准

可选数据可能带来差异化优势，但也可能过时、有偏、受法律限制、匹配错误，或根本无法解释。不要仅仅因为存在连接器就将其接入。

对于每个可选来源，完成以下决策卡：

如果团队无法回答这些问题，就应隔离该来源，而不是把它放进自动评分中。

五项 AI 谈判数据就绪性评分卡

在已审阅来源中，并不存在一个权威且普适的完整性百分比阈值。更好的方法是测试预期工作流能否成功执行。

对每项测试评分为 通过、有条件通过 或 失败：

1. 身份测试： 团队能否将每个受邀供应商与正确的法律实体及下游标识符对齐？
2. 可比性测试： 两份报价能否在一致的范围、单位、币种、期间、地点和条款下进行比较？
3. 可复现性测试： 独立审查者能否复现评分，并理解排除项或调整项？
4. 权限测试： 每个重要步骤是否都会路由给具备适当权限的指定人员？
5. 可追溯性测试： 审查者能否看到每项关键输入的来源、生效日期、转换过程和变更历史？

部署规则

• 可在受控工作流下推进： 所选用例的五项测试全部通过。
• 仅在有书面控制措施时推进： 有条件通过项必须有指定负责人、替代方案和截止日期，且在未经审查前不得改变供应商资格、评分或承诺。
• 延迟受影响能力： 任何失败涉及供应商身份、单位、币种、评估逻辑、权限或来源追溯。

因此，团队可以先上线基础事件管理，同时推迟AI生成评分或建议。这比笼统地宣称整个组织“数据尚未就绪”更精确。

假设示例：设施维护寻源

以下示例为假设场景，包含说明性假设，并非基准数据。

某企业采购团队计划开展区域性设施维护事件。它拥有干净的供应商ID、联系人、站点清单、服务描述、响应币种、合同日期、通过/不通过的保险要求、已批准的评分规则以及授标工作流。但它的服务历史数据较为零散，也缺乏可信的外部人工基准。

根据 M-U-O 模型：

• 团队具备运行受控事件所需的 最低 数据。
• 零散的服务历史可能是 实用 数据，但前提是先对站点和报告期间进行对齐。
• 外部人工基准在采购确认地理范围、岗位定义、生效日期和许可条件之前，属于 可选 数据。

团队继续推进该事件，但不会让系统自主生成绩效评分或人工成本目标。采购分析师审查历史服务记录，运营部门验证范围，财务检查评估模型，授权决策组批准授标。

这避免了两种常见错误：一是等到每个数据源都完美后才推进任何工作；二是仅仅因为软件可以处理，就把薄弱数据当成精确数据。

将事实、假设、估算和建议分开

决策记录应清晰区分四类证据。

已验证事实

这类信息有明确来源和生效日期支持——例如已签署合同价格、供应商提交的报价或已批准的交付记录。像开放合同数据标准这样的标准化合同模型，会区分买方、供应商、招标、授标和合同，这说明实体和阶段区分为何重要（source）。

假设

这是尚未验证的规划前提，例如预期需求或利益相关方对切换时间的估计。应标注负责人和复审日期。

估算

这是计算或建模得出的数值，例如标准化总成本或预测。应保留方法、输入、相关范围或不确定性，以及审查人。

建议

这是关于应采取何种行动的判断。它们可以使用事实、假设和估算，但不能被展示为事实。AI谈判建议并不会自动产生机构授权。

一个简单的证据标签可以采用以下格式：

类型： 事实 / 假设 / 估算 / 建议
来源或方法：
生效日期：
负责人：
置信度或限制：
必需审批人：

在关键关口，人工审批仍然是强制性的

NIST AI RMF 1.0 指出，应清晰区分决策中的人工角色与AI监督角色，并指出将复杂判断简化为可测量变量，可能会丢失重要背景（source）。

以下事项应由具名、可追责的人审查或批准：

• 范围、规格和需求假设
• 受邀供应商及任何排除决定
• 强制标准、权重、公式和商务规则
• 响应是否真正可比
• 有条件、模糊、异常或不合规的报价
• 基准相关性和底线立场
• 法律、竞争、制裁、冲突、隐私和声誉问题
• AI生成的目标、建议或谈判边界
• 发布后的标准或权重变更
• 所选情景、授标理由、例外情况和合同承诺

NIST 还区分了具有法律、财务或政策权限的参与者，与技术和运营层面的AI参与者（source）。应围绕具名角色配置审批；不要暗示平台本身可以授权承诺。

实施失败通常发生在哪里

将完整性误认为准确性

字段已填并不意味着其中的法律实体、单位、币种、站点或合同版本就是正确的。

将更多数据误认为更好证据

大量电子邮件和转录档案可能包含个人信息、特权信息、重复内容或无关材料。采集应遵循隐私、法律、安全和保留审查。

将供应商声明当作已验证事实

问卷回答、认证、产能说明和可持续性声明，可能需要独立验证。

分数掩盖了政策选择

加权和标准化是决策，不是中立的机械过程。它们需要审批和版本控制。

外部风险数据匹配错误

一条新闻或风险标记可能指向关联公司、同名公司或已过时实体。实体解析和生效日期至关重要。

AI输出带来虚假精度

预测行为或AI推导目标可能有助于情景讨论，但在未经来源审查、不确定性评估和批准之前，不应成为承诺边界。

一个实用的实施顺序

1. 选择一个边界清晰的工作流。 选定一种谈判类型、一个品类和一个业务单元。
2. 映射规范记录。 定义供应商、事件头、行项目、响应、评估、授标和审批对象。
3. 验证最低层。 让身份、单位、币种、日期、规则和权限可被机器校验。
4. 运行五项就绪性测试。 使用真实工作流样本，包括一个例外情况和一个不合规响应。
5. 加入实用背景。 在使用前先标准化历史、合同、绩效和风险数据。
6. 控制可选增强。 要求填写可选数据决策卡，并设置人工检查点。
7. 监控覆盖操作。 记录是谁覆盖了某项建议以及原因；调查原因是数据差、规则差，还是背景缺失。

正在考虑商业化 Negotiation platform 的团队，可以用这一顺序来测试数据与工作流的适配性，而不必假设完整的历史数据是前提条件。关于寻源事件和受控供应商工作流的系统能力，请参见 procurement negotiation software。当企业采购使用 Negotiations.AI 来组织已寻获的证据、保留审批边界并支持可审查的谈判准备时，它才会在具体工作流中体现价值；但这些能力仍应根据组织自身要求进行验证。

如需更广泛的工作流视角，请阅读 A Negotiation Platform Use-Case Map from Prep to Learning。如需通过测试而不是依赖功能清单来评估，请参见 Evaluate a Negotiation Platform with Real Workflow Tests。

常见问题

没有干净的历史支出数据，我们能实施谈判平台吗？

可以，对于边界清晰的工作流，只要最低限度的运营和治理数据是可靠的即可。即使没有完整的历史支出库，你也可以发起事件并收集可比响应。在历史数据完成标准化和审查之前，不要将不可靠的历史数据用于基线、自动评分或谈判目标。

哪些数据问题应该阻止上线？

当团队无法信任供应商身份、范围、单位、币种、日期、评估规则、审批权限或关键来源追溯时，应停止或限制受影响的能力。这些缺陷会破坏可比性和授权。缺少可选的市场数据源通常不应阻止受控工作流。

供应商风险数据是必需的吗？

这取决于事件和政策。必需的资格、排除、制裁、安全或资质检查可能属于最低数据。更广泛的绩效、财务、运营或声誉指标通常属于实用数据。预测和负面媒体信号通常属于可选数据，直到实体匹配、相关性、生效日期和允许用途都得到验证。

谈判平台数据需要完整到什么程度？

并不存在适用于所有组织的、基于证据的通用百分比。应测试执行效果：有效邀请、可比提交、可复现评估、授权审批、可追溯输入，以及成功传递到下游系统。

AI谈判数据就绪性是否允许自动授标？

本身并不允许。更好的数据可以改善分析，但不会赋予权限。供应商排除、重大评分变更、授标选择、例外处理和合同承诺，仍应根据组织政策和适用要求接受具名人工审查和批准。

延伸阅读

• NIST Artificial Intelligence Risk Management Framework 1.0
• NIST Generative Artificial Intelligence Profile
• Open Contracting Data Standard schema reference
• Oracle: Negotiation Lines
• Oracle: Negotiation Terms

免责声明：本文提供一般性运营信息，不构成法律、财务、合规或采购政策建议。