技术问题定义

智能运维平台的选型文档通常写得很好看：能力清单、架构图、实施计划一应俱全。但工程侧真正关心的是另一件事——哪些结论可以在上线前被验证。

评审会上"支持流程自定义"“支持智能问答”“支持多维报表"这类表述，都属于能力声明而非验收项。能力声明无法直接验收，因为它没有回答"在什么条件下、由谁操作、观察到什么结果才算通过”。本文讨论的，是如何把能力声明翻译成可验证的验收项，不涉及具体接口与实现细节，具体能力以官方产品说明为准。

一、验收项需要具备的三个属性

一条表述能成为验收项，至少要满足三点：

可观察：结果能被第三方看到，而不是只有实施方知道。例如"响应时效缩短"要看平台报表里的分布数据，而不是听结论。

可复现：换个操作员、换个时间段重复执行，结果一致。依赖特定人员经验才能完成的动作，不应写进验收清单。

可归因：未通过时能定位到具体环节，是配置问题、数据问题还是集成问题。

按这三条过滤一遍，大部分能力声明会露出原形：有些无法观察，有些只在特定数据下成立，有些失败后无从定位。

二、按阶段拆验收清单，而不是按模块

按模块拆清单容易出现"每个模块都通过、整体跑不通"。更合理的是按阶段拆解：

阶段一，配置验证。 核心是"不改代码能配到什么程度"。建议的验证动作是：新增一类服务请求，改变它的审批链路与处理人规则，观察是否可在后台完成。这个动作直接检验平台是配置驱动还是定制驱动，也与流程引擎的表达能力、字段与权限的可配置粒度直接相关。

阶段二，链路验证。 核心是"端到端 是否闭环"。从用户提交请求开始，经过智能推荐、人工补位、工单流转、处理反馈，到知识沉淀，任一步骤断掉都会在后续放大。验证时建议覆盖三类请求：可被智能直接解答的、需要人工介入的、需要跨团队协同的。

阶段三，运营验证。 核心是"服务过程产生的数据能否回到管理侧"。至少应能看到响应时效分布、未闭环单据分布、同类问题重复率三项，并确认它们可被导出或对接到既有管理流程。

三、四个关键工程问题

其一，流程配置的边界。配置能力通常有边界——哪些字段可改、哪些节点可增删、条件表达式支持到什么粒度。边界应写进验收清单，而不是默认"都能配"。

其二，知识的更新机制。智能回答的质量取决于知识，因此要验证知识库 的来源、更新频率与维护方式：标准知识由谁提供，企业自有知识如何录入，答错的案例如何回流修订。

其三，数据回流口径。报表里的指标定义要提前对齐：响应时效从哪个时间点起算，闭环以什么状态为准，跨团队协同的时间如何归属。

其四，集成边界与失败处理。与外部系统对接时，除了成功路径，还要明确失败时如何重试、如何告警、是否会丢失单据。这一项常被遗漏，却是上线后故障的主要来源。

四、集成与开放性

智能运维平台通常需要与既有业务系统、身份体系与消息通道打通。工程侧应关注三类开放性：身份与组织数据的同步方式、服务请求的入口可扩展性、以及服务数据对外输出的接口形式。

需要强调的是，集成范围应服务于"统一运维集中管理"这一目标，而不是追求对接数量。用友智能服务管理器YonISM 支持与用友 NC、NC Cloud、YonBIP 等服务系统协同，并可接入第三方系统；同时依托可视化流程引擎与灵活的 组织、权限配置适配企业架构，具体集成与配置能力以官方产品说明为准。

五、工程落地建议

验收清单在选型阶段就提出，而不是上线前补写，否则容易演变成双方妥协的产物。

试运行期保留线下通道，确认平台链路稳定后再收敛入口。

把"平均实施周期约 2 周即可上线"这类口径写进计划时，需同时标注：具体实施周期因企业场景而异，请以官方售前评估为准。