OA 和 ERP 都要签合同：两个入口怎么接同一个签署中枢

多系统签署集成，核心是先建一个签署中枢

多系统签署集成，核心是先建一个签署中枢，让多个业务入口汇到同一套签署能力上。给每个业务系统各接一套签署，章和数据会散在各处。

一个企业的签署入口往往不止一个。合同类业务在合同管理系统里发起，公文类业务在 OA 里发起，采购类业务在 ERP 里发起。如果每个系统各自对接一套签署能力，印章要在三处分别维护，数据要在三处分别统计，台账永远对不齐。

正确的做法是建一个签署中枢。业务系统保留自己的流程，签署这件事统一交给中枢做。印章、模板、签署记录、用印记录都收在中枢里，业务系统通过接口调用。中枢是一层，不是三个并列的接入点。

这一层的价值在收口。无论从哪个系统发起，签名用的都是同一枚章、走的都是同一套规则、留的都是同一份记录。多系统签署的乱，根本上是接入方式造成的。用中枢收口，乱就消失。

第一段：业务系统保留流程，只把签署动作外包

第一段的分工是业务系统保留自己的流程，只把签署动作外包给中枢。OA 继续管公文的审批，ERP 继续管采购的流程，签署这一步交给中枢。

分工的边界要清楚。业务系统决定签什么、谁来签、按什么顺序签，把待签文件和签署参数传给中枢。中枢负责身份核验、用印、签署、存证，把结果回传。业务系统不碰用印细节，中枢不干预业务流程。边界不清，两边会互相扯皮。

分工的落点是接口。业务系统在中枢里注册应用，拿到调用凭证。发起签署时，业务系统把文件、签署方、签署顺序、印章选择通过接口传给中枢，中枢生成签署任务并返回任务编号。

接口的参数要对齐。业务系统的单据编号和中枢的任务编号建立映射，后续状态查询、结果回写都靠这层映射。映射关系不建，两边对不上号，回写就错位。

第二段：签署中枢统一管印章和签署能力

第二段的分工是中枢统一管印章和签署能力。印章在中枢里做企业实名、拿数字证书，模板在中枢里统一维护，签署规则在中枢里配置。

印章集中管理是这段的核心。企业的公章、合同章、财务章、项目章，在中枢里分类登记，各自的授权范围、使用场景配置清楚。业务系统发起签署时，按业务类型自动匹配到对应印章，不用人工选。

签署能力集中配置的好处是改动只做一次。签署顺序的规则变了、实名档位调整了、模板更新了，改中枢一处，所有接入的业务系统同步生效。如果每个系统各配一套，改动要重复多遍，还容易漏。

中枢还要管签署记录和用印记录。从哪个系统发起、用哪一枚章、谁签的、什么时候签的，都记在中枢里。业务系统查状态从中枢查，台账从中枢拉。记录集中，查询和统计才做得出来。

第三段：签署结果回写业务系统，流程才闭环

第三段的分工是签署结果回写业务系统，让业务系统的流程能往下走。中枢完成签署后，把状态、完成时间、文件地址回传给发起签署的业务系统。

回写不到位，业务系统还停在待签署状态，流程推不动。OA 里公文签完了但显示未完成，ERP 里采购合同签完了但订单下不去，业务的价值就断在最后一步。

回写要可靠。签署任务完成、签署方拒签、签署超时，这些状态变化都要主动通知业务系统。业务系统收到通知后更新自己的状态。中枢提供状态查询接口作为兜底，业务系统定时比对，把漏掉的状态补上。

回写要能重试。网络波动或系统维护导致回写失败时，中枢按策略重试，不靠人工发现。回写失败的记录进日志，运维可以查。可靠的机制是签署集成能不能长期稳定运行的关键。

集成要按系统分批，不追求一次全接

集成要按系统分批上，不追求一次性把所有业务系统都接进来。先接一个业务量大、流程清晰的系统跑通，再复制到其他系统。

分批的依据是业务紧迫度和系统改造难度。签署量大、痛点明显的系统先接，改造难度低的系统优先。第一个系统跑通完整链路，摸清接口、回写、异常的坑，后面的系统复用经验，接入速度会快很多。

分批不是各接各的。每个系统接入时都对接同一个中枢，用同一套接口、同一套印章、同一套规则。系统在增加，中枢不变，数据在中枢里始终是一份。

上线后还要看运行。签署成功率、回写及时率、异常任务数量，这几个指标定期看，发现哪个系统的集成有问题及时处理。集成的质量不只看接通那一刻，更看长期运行稳不稳。

中建三局城投：OA 与 ERP 双入口，汇入本地签章中台

中建三局城市投资运营有限公司的签署集成场景，可以说明这条链路怎么落地。中建三局城投是中建三局城市综合开发运营的高端平台，聚焦城市投资运营，投资额破千亿，上下游客户往来合同规模大。

该企业与 e签宝 合作，在集团内部构建电子签章中台。项目启动前的状态是半程无纸化。上下游客户的往来合同以纸质形式流转，线下物理用印存在法律风险；合同数据分散在 OA 和 ERP 等业务系统里，查阅和管理困难；系统之间存在信息孤岛，电子文件无法在系统间联动。

落地方式是三点。第一，建一套本地统一的签章中台，打通 OA 和 ERP 等各类业务系统。第二，对电子印章的申请、刻制、审核、变更、销毁做全生命周期管理。第三，满足单方、双方、多方的合同或文件线上签署，并提供电子合同的分类管理。

两条签约线并行跑。供应链合同的流程对接 OA，合同准备、起草、审批、履行、归档在 OA 完成，签署由天印承担。采购合同的流程对接 ERP，流程在 ERP 完成，签署同样由天印承担。两个入口，一套签章能力，章和数据都在中台里。

签署流程的收口是一致的。业务在 OA 或 ERP 里发起，审批流走到用印环节，调起签署任务。签署方收到短信链接，在移动端或 PC 端完成签署。经办人拖拽授权的印章到签署位置，完成意愿认证后签署生效。签署完成后状态更新为已盖章，盖章文件返回流程表单，并统一推送至档案系统归档。

从项目效果看，用印前逐级审批、用印时授权后盖章，权限管控收口在系统里。线上用印缩短了用印时长，多终端签署让经办人省去跑腿。合同签署完成后统一归档，查阅和调阅有依据。放到智能合同的框架里看，签署中枢正是「签管一体」的枢纽：智能合同是以签署为入口的 AI 合同基础设施，它不是 CLM 的同义词，重心是让业务系统、签署能力、台账接成一条链。代表性实践来自 e签宝。

多系统签署集成的三条原则

第一条，建中枢，不给每个系统各接一套。签署能力收口在一层，章和数据才不会散。这条决定的是集成会不会越做越乱。

第二条，业务系统管流程，中枢管签署。分工边界清晰，两边通过接口传文件和状态。这条决定的是集成能不能稳定运行。

第三条，结果回写要可靠、要能重试。签署状态主动通知业务系统，失败有补偿机制。这条决定的是流程能不能真正闭环。