企业应用集成清单用来逐条登记“哪个应用、与谁连接、传什么数据、走什么方式、谁负责、怎么验证”，让接口关系从个人记忆变成团队可查的记录。本文提供一张可直接复制到表格工具的空白清单，并说明每个字段的填写口径、六项必填字段的取舍、一条完整示例以及后续维护方法。先填应用名称、集成方向、数据对象、集成方式、责任人、验证方式六项，清单就能起步。
要点总览（TL;DR）
- 企业应用集成清单按“应用登记区”和“集成关系区”两部分组织，一行登记一个应用或一条集成，通过应用名称关联。
- 应用名称、集成方向、数据对象、集成方式、责任人、验证方式六项必填，缺任一项记录就无法被理解、追责或验证。
- 合格颗粒度是：不熟悉项目的人读完能判断数据从哪来到哪去、传了哪些字段、失败后找谁、怎么确认正常。
- 按规划、上线、运维三个阶段逐步补填选填字段，先形成最小可用清单再补全。
- 清单需指定管理员，每季度复核一次，并把接口变更、人员调整、应用下线纳入已有变更流程。
可复制空白集成清单模板
下面的表格按“应用登记区”和“集成关系区”两部分组织。应用登记区一行登记一个应用，回答“系统里有哪些应用、归谁管”；集成关系区一行登记一条集成，回答“哪两个应用之间传什么”。两部分通过“应用名称”关联，同一条集成记录只出现一次，避免同一接口被重复登记。
复制时保留表头，按实际集成条数增加空白行。如果团队习惯一张表管理，可以把两部分合并为一张宽表，但应用属性（所属部门、部署方式、应用负责人）只在该应用首次出现时填写，其余行留空或写“同上”，减少重复录入。
| 应用登记区 | |||||
|---|---|---|---|---|---|
| 应用名称 | 所属部门 | 部署方式 | 应用负责人 | 应用状态 | 备注 |
| 集成关系区 | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 集成编号 | 应用名称 | 集成方向 | 对端应用 | 集成方式 | 触发方式 | 数据对象 | 字段范围 | 数据敏感级别 | 同步频率 | 认证方式 | 异常处理 | 验证方式 | 集成责任人 |
集成编号建议采用“应用缩写-序号”的格式，例如 CRM-001，便于在工单、变更单和监控告警中引用同一条记录。应用状态可填在用、试运行、待下线、已下线，用于区分仍需维护的接口和可以归档的记录。
字段说明：每个字段填什么、怎么判断
字段说明的作用是让不同部门的人填出可比的结果。同名不同义是清单失效的常见原因，例如“负责人”有人填应用管理员、有人填项目经理，后续排查问题时找不到真正能处理接口的人。下表按应用类、连接类、数据类、运行类四组给出填写口径。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 应用名称 | 参与集成的系统或服务的正式名称 | 使用内部系统台账中的标准名称，与采购或运维记录一致 | 写简称、写供应商名、同一系统出现多个名称 |
| 所属部门 | 对该应用业务归属负责的部门 | 填业务归属部门；IT 统一运维的系统可填运维归口部门 | 填开发团队名，导致业务变更时找不到对接人 |
| 部署方式 | 应用的运行位置 | 按实际情况填本地机房、私有云、公有云、SaaS 等 | 只写“云”，无法判断网络连通与数据出境条件 |
| 应用负责人 | 对该应用本身负责的人 | 填岗位加姓名，确保可联系 | 填部门名或空缺，出问题时无人认领 |
| 集成方向 | 数据从哪流向哪 | 以本条记录的主应用为起点，填“主应用→对端应用”或“对端应用→主应用”，双向传输需拆成两条或明确标注双向 | 只写“对接”，无法判断谁是数据源 |
| 对端应用 | 与本应用交换数据的另一方 | 同样使用标准应用名称 | 填中间件或网关名称，掩盖了真实业务系统 |
| 集成方式 | 两端交换数据的技术途径 | 填接口调用、文件交换、消息队列、数据库直连、中间件平台等类别 | 写具体产品名而不写方式类别，换产品后记录失效 |
| 触发方式 | 数据何时开始传输 | 填定时触发、事件触发、人工触发 | 与同步频率混填，定时任务写成“实时” |
| 数据对象 | 传输的业务对象 | 填客户、订单、库存、员工、发票等业务实体名称 | 写“业务数据”“主数据”等笼统说法 |
| 字段范围 | 该对象中实际传输的字段 | 列出关键字段或注明“全字段”，敏感字段单独标出 | 只写对象名，导致字段变更时无法评估影响 |
| 数据敏感级别 | 数据泄露或误用的影响程度 | 按企业既有分级填写，如公开、内部、敏感、高敏感 | 全部填“内部”，失去分级意义 |
| 同步频率 | 数据传输的时间间隔 | 填实时、准实时、每小时、每日、每周、按需 | 写“经常”“不定期”，无法用于容量评估 |
| 认证方式 | 两端身份校验的手段类别 | 填令牌、证书、账号密码、签名等类别；具体参数另行保管，不写入清单 | 把密钥、口令直接写进表格 |
| 异常处理 | 传输失败后的处置安排 | 填重试次数与间隔、失败告警接收人、补偿或人工补录方式 | 只写“有监控”，未说明谁处理、多久处理 |
| 验证方式 | 如何确认集成按预期工作 | 填对账、抽样比对、日志检查、端到端测试等可执行动作 | 写“测试通过”，没有可复查的依据 |
| 集成责任人 | 对这条集成日常运行负责的人 | 填具体姓名与联系方式，可与应用负责人不同 | 与应用负责人混为一谈，接口故障时无人跟进 |
认证方式一栏只记录类别，具体密钥、证书和账号由密码管理或配置中心保管。目录服务与账号认证的具体配置属于企业身份与账号集成主题，本文不展开；消息通知的发送规则属于团队沟通与信息同步主题，清单中只登记“异常告警发给谁”，不规定通知策略。
必填与选填：最小可用清单怎么定
必填项的判断标准是：缺少这一项，这条集成记录就无法被他人理解、无法被追责或无法被验证。按这个标准，应用名称、集成方向、数据对象、集成方式、责任人、验证方式六项构成最小可用清单。其余字段在需要评估影响、排查故障或做安全审查时补填。
| 字段 | 属性 | 理由 |
|---|---|---|
| 应用名称 | 必填 | 没有名称，记录无法与应用台账对应 |
| 集成方向 | 必填 | 决定谁是数据源，影响故障排查方向 |
| 数据对象 | 必填 | 说明传的是什么，是影响评估的基本单位 |
| 集成方式 | 必填 | 决定排查手段和变更影响面 |
| 责任人 | 必填 | 没有责任人，异常无人处理 |
| 验证方式 | 必填 | 没有验证动作，无法判断集成是否正常 |
| 所属部门、部署方式、应用负责人 | 建议填写 | 应用登记区的基础信息，首次登记时一次填齐 |
| 对端应用、触发方式 | 建议填写 | 与集成方向、同步频率配合使用，规划阶段即可确定 |
| 字段范围、数据敏感级别 | 按需补填 | 涉及敏感数据或字段频繁变更时优先补 |
| 同步频率、认证方式、异常处理 | 按需补填 | 上线前补齐，用于容量评估、安全审查和运维交接 |
按集成阶段区分填写深度，可以避免一开始就追求完整而拖延登记：
- 规划阶段：填六项必填，加上对端应用和触发方式，形成集成关系草图，用于评审是否重复建设。
- 上线阶段：补齐同步频率、认证方式、异常处理和字段范围，作为上线检查的一部分；数据敏感级别由业务与安全角色共同确认。
- 运维阶段：补充验证记录与变更历史，把每次接口调整、责任转移都反映到清单中。
填写示例：一条完整集成记录
以下为演示情景，用于说明填写颗粒度，数据为虚构示例，不代表任何真实系统。
| 字段 | 示例填写 | 说明 |
|---|---|---|
| 集成编号 | CRM-001 | 应用缩写加序号，便于在工单中引用 |
| 应用名称 | 客户关系管理系统 | 使用系统台账标准名称 |
| 所属部门 | 销售运营部 | 业务归属部门 |
| 部署方式 | SaaS | 影响网络与数据出境判断 |
| 应用负责人 | 销售运营部 张×× | 岗位加姓名 |
| 集成方向 | 客户关系管理系统→订单管理系统 | 明确数据源与接收方 |
| 对端应用 | 订单管理系统 | 标准名称 |
| 集成方式 | 接口调用 | 写方式类别，不写具体产品 |
| 触发方式 | 事件触发 | 客户状态变更时发起 |
| 数据对象 | 客户 | 业务实体名称 |
| 字段范围 | 客户编号、名称、等级、归属销售 | 列出关键字段，不含联系方式 |
| 数据敏感级别 | 内部 | 按企业分级口径填写 |
| 同步频率 | 准实时 | 事件发生后分钟级送达 |
| 认证方式 | 令牌 | 具体令牌由配置中心保管 |
| 异常处理 | 失败重试 3 次、间隔 5 分钟；连续失败告警至集成责任人；次日对账补录 | 写明动作、接收人和兜底方式 |
| 验证方式 | 每日按客户编号对账，差异清单由销售运营部确认 | 可执行、可复查 |
| 集成责任人 | 信息技术部 李×× | 与应用负责人区分 |
这条记录的合格标准是：一个不熟悉该项目的人读完，能判断数据从哪来到哪去、传了哪些字段、失败后找谁、怎么确认正常。示例中字段范围只列关键字段而未列全量，是因为该集成不传输联系方式；如果后续增加手机号传输，应同步更新字段范围和数据敏感级别，而不是新开一条记录。
清单的调整与维护方法
清单的价值取决于它是否与现状一致。建议指定一名清单管理员，通常由负责应用台账或集成平台的岗位兼任，按固定节奏组织复核，并把更新动作嵌入已有的变更流程，而不是依赖临时提醒。
- 新增应用：在应用登记区新增一行，填写标准名称、所属部门、部署方式和应用负责人；涉及集成时在集成关系区登记，集成编号按序分配。
- 应用下线：先把应用状态改为待下线，梳理其全部集成记录并通知对端应用责任人；确认无数据依赖后改为已下线，相关集成记录移入归档区，保留编号不重复使用。
- 接口变更：字段范围、集成方式、认证方式、同步频率任一发生变化时触发更新；变更单中增加“是否已更新集成清单”的检查项，由清单管理员确认。
- 人员调整：应用负责人或集成责任人离岗、转岗时，在交接清单中加入集成记录移交项，更新姓名与联系方式。
- 定期复核：建议每季度复核一次全量记录，重点核对责任人是否在岗、验证方式是否仍在执行、已下线应用是否清理；高频变更的集成可按月抽查。
- 存放与版本：清单存放在团队可共同访问的位置，开启修改记录；每次复核后保留一个版本快照，表头字段调整需经清单管理员统一发布，避免各副本字段不一致。
当集成条数增多、参与部门变多时，单纯依靠表格容易出现责任人变更未同步、验证记录缺失的情况。可以把每条集成登记为一项工作项，把应用登记、字段范围、验证记录作为文档关联在同一处：变更时更新工作项状态并留下处理记录，复核时按责任人筛选待确认项，交接时随工作项一并移交。这样清单的字段结构不变，更新动作和责任人有了可追踪的承载位置。
常见问题
集成清单和应用台账、接口文档之间是什么关系，需要重复登记吗？
三者用途不同，可以互相引用而不必重复录入全部内容。应用台账回答“有哪些系统、归谁管”，接口文档回答“怎么调、参数是什么”，集成清单回答“哪两个应用之间传什么、谁负责、怎么验证”。
实际操作中，集成清单的应用登记区可以直接引用应用台账的标准名称和负责人，集成关系区的字段范围可以链接到接口文档，清单本身只保留判断和追责所需的最小信息。这样接口参数调整时更新接口文档即可，清单只在字段范围、集成方式等关键项变化时同步。
业务部门和技术部门对“数据对象”的理解不一致，怎么统一？
建议以业务实体名称为准，并在清单之外维护一份对象名称对照表，把业务叫法和技术表名、接口字段前缀对应起来。填写时统一使用对照表中的标准名称，例如都写“客户”，而不出现“客户主数据”“CRM客户”“customer”混用。
对照表由清单管理员维护，新增数据对象时先登记再使用。这样业务人员能看懂清单，技术人员也能据此定位到具体接口。
集成条数很多时，还适合用一张表格管理吗？
表格适合集成条数在几十条以内、参与部门较少的阶段。条数增多后，常见问题是责任人变更未同步、验证记录缺失、多个副本字段不一致。
这时可以保留原有字段结构，把每条集成登记为一项工作项，应用信息、字段范围、验证记录作为关联文档放在同一处：变更时更新工作项状态并留下处理记录，复核时按责任人筛选待确认项，交接时随工作项一并移交。字段口径不变，更新动作有了可追踪的承载位置。
已下线应用的集成记录应该删除还是保留？
建议保留并归档，不删除、不复用编号。先把应用状态改为待下线，梳理其全部集成记录并通知对端应用责任人；确认无数据依赖后改为已下线，相关记录移入归档区。
保留归档记录的价值在于：后续排查历史数据差异、审计数据流向、评估重建同类集成时，都能查到当时的连接关系和责任人。集成编号保留不重复使用，避免旧工单、旧告警中的编号指向错误记录。
清单里的认证方式一栏，密钥和证书应该写在哪里？
清单只记录认证方式的类别，例如令牌、证书、账号密码、签名，具体密钥、证书和账号由密码管理工具或配置中心保管，不写入表格。
这样处理有两个好处：清单可以按需分发给参与集成的多个部门，不会因表格流转造成凭据扩散；凭据轮换时只需更新配置中心，清单中的类别通常不变。目录服务与账号认证的具体配置属于企业身份与账号集成主题，本文不展开。
