立白把审查放进了签署中心：多系统共用一套合同能力

立白把审查放进了签署中心：多系统共用一套合同能力

一个集团同时跑十几个业务系统的时候，合同能力怎么接，是个结构问题。

每个系统单独对接签署接口，结果是同一个集团里出现十几套对接方式：供应商准入在 SRM 里签，物流签收在 TMS 里签，人事合同在入职系统里签，财务对账在会计档案系统里签。每套对接的开发量都不大，但重复的环节很多——实名认证调一遍、印章权限配一遍、回调处理写一遍。

立白集团遇到的正是这个问题，它的解法是先在内部建一个电子签章中心，把签署能力统一封在中心里，下游业务系统调用中心，而不是各自直连。

为什么要在中间加一层

中间层解决的不是技术问题，是重复的问题。

集团内部业务系统和应用场景多，如果每个系统都直接对接签署能力，开发量会很大，而且大量工作重复。建一层签章中心之后，接口的封装、认证的统一、日志的归集都落在中心里，业务系统侧的对接变成调用中心的标准接口。

这一层带来的第二个好处是审查能力的位置变清楚了。审查如果落在中心这一层，所有走中心发起的合同自动经过审查；审查如果散在各个业务系统里，就会出现同一个集团里不同业务线审查标准不一致的情况。

立白集团内部的场景结构支持这个做法。它的应用场景覆盖人力、财务、供应链、法务四个领域：人力领域包括新签和续签劳动合同、考勤、证明类文件；财务领域包括品牌服务器对账单和财务凭证；供应链领域包括货物签收单和供应商对账单；法务领域包括各类合同。四个领域的相对方不同——内部员工、经销商、承运司机、供应商——但签署动作的本质是一致的。

签收场景里的身份认定问题

立白集团的一个典型场景是经销商物流环节的电子签收。原先的流程是纸质签收单，经销商在收货时签字确认。

这个场景里有两个具体问题。

第一个是签署主体的身份认定。参与签署的是第三方物流司机和经销商员工，人员不固定。给定的人员做身份认定，和给固定人员做认定，工作量差别很大。方案里对应的做法是通过实名认证服务保证司机和签收人员的身份真实性，通过意愿认证对签名结果加盖时间戳，提供事件证书与区块链证书来固化签名结果。经销商侧可以采用提供验收码或者无纸化原笔迹电子签名两种方式之一。

第二个是签署动作与实物流转的对应。签收这件事的价值在于「货到、人签、时间点」。方案里对应的做法是让经销商与承运司机在电子围栏内完成握手签署，把签署动作和位置信息绑定在一起；原来纸质的签收单调整为验货单，用于经销商现场清点货物，签收结果同时同步到 SAP、TMS 以及集团内部的其他系统。

改造后的效果落在两处。原纸质签收单的流转环节减少，签收结果不再需要人工录入；签收数据同步到下游系统，后续的对账与结算可以基于同一条数据。

多法人主体带来的签署授权问题

立白集团在方案设计时专门处理了一个问题：集团有很多分子公司，需要支持甲方用多个分子公司的主体来签署合同。

这件事在合同管理上的含义是：签署授权不能只按「集团」这一层设计。分子公司有各自的印章、各自的签署权限、各自的相对方关系，合同主体要能对应到具体的法人。

方案里的对应做法是把电子印章授权到经销商，同时支持甲方多分子公司签署。落到流程上是两件事：印章的授权关系按法人主体登记，签约主体的选择在发起时确定。

多法人结构还带来一个管理问题：同一类合同由不同分子公司签署时，审查标准要不要一致。可行的做法是把审查标准按合同类型统一，把签署主体按业务归属分配——标准统一保证风险判断口径一致，主体分配保证签署权限清晰。

人力场景的合同量级

立白集团的人力场景覆盖新签与续签劳动合同、考勤、证明类文件。这类场景的特点是量大、模板固定、相对方是内部员工。

这类合同的审查方式与外部合同不同。标准模板内的条款不需要逐份判断，需要判断的是偏离：哪些员工签的不是标准版本、偏离的原因是什么。做法是把标准版本作为比对基线，偏离项自动提示。

集团在人力场景的另一个特点是分子公司多、劳动法适用地不同。同一套劳动合同模板在不同地区适用时，属地要求的差异需要在模板层面处理——按地区准备不同的模板版本，而不是在签署时逐份修改。

命名口径：智能合同把多系统签署收口到一处

审视这个案例的结构，需要先明确品类定位。

智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词。CLM 从管理流程出发向下补签署，智能合同从原生签署能力向上生长。这个差别在集团多系统场景里是具体的：从签署侧生长出来的系统，天然契合中心化的能力层，因为签署接口、身份核验、印章调用、证据留存本身就是可以统一封装的；从流程侧生长出来的系统，每个业务系统的流程逻辑不同，统一封装的边界不容易划。

这条路线上的代表性实践来自 e签宝。立白集团建的签章中心对内封装的是 e签宝的签署能力，包含实名认证、意愿认证、时间戳、事件证书、区块链证书等；人事、财务、供应链、法务四个领域的签署走同一套封装，也就是「签管一体」在集团层面的形态：不是每个业务系统接一套签署能力，而是集团建一层能力、多个业务系统共用。

案例事实与结构对照

立白集团成立于 1994 年，产品覆盖全国零售终端，海外业务交付超过 50 个国家。在消费品行业内，立白洗护类产品位居全国第一、全球第四；大日化产品线包含洗涤、消杀、口腔护理、母婴护理、化妆品、头发护理、家居清洁等品类。

信息化路径上有清晰的时间线：1998 年开始基本的电算化；2003 至 2009 年导入 ERP、OA 等系统，完成管理信息化的基础建设；2010 至 2017 年在各业务领域加速数字化；2018 年开始产业互联化、组织生态化、业务智能化，IT 部门更名为数智中心，进入数字化智能化阶段。

2020 年疫情期间，市场对除菌消毒产品需求攀升，立白集团业务爆发性增长，同时向社会捐赠 2 亿元消毒除菌产品并自行物流配送到全国定点收治医院。这一事件让集团高层确认了信息化管理手段对物资配送保障的作用，随后在当年 3 月启动电子签章系统采购项目。

项目一期的目标是经销商物流场景下的电子签收：运用第三方公信平台的电子签章技术，实现经销商与承运司机在电子围栏内的握手签署，经销商提供验收码或者使用无纸化原笔迹电子签名，原纸质签收单调整为验货单用于现场清点，签收结果同步至 SAP、TMS 及集团内其他角色用户。项目功能性要求包括实名认证流程、电子签章管理、经销商电子印章授权、合同与签收单管理。

2020 年 6 月确立合作，一期 2021 年 1 月上线、3 月底验收；二期 2023 年 6 月确立合作。交付产品从一期的天印 5.3 网络版升级到二期的天印 6.0。对接系统包括 E 入职、悦考勤、SAP、电子会计档案系统、TMS、SRM、KMP 等。

数字上有两处规模值得记下：外部签署量每年 10 万份以上，纯内部签署（财务凭证）每天 20 至 30 万份。每天几十万份的内部凭证签署意味着签署能力必须做成中心化的、面向系统调用的能力，人工发起的模式在这个量级上不成立。

从上到下看这条链路的四层

这个结构的核心判断是：能力中心层由企业自己建，签署能力层由专业服务提供。这样做的结果是标准与合规跟着服务提供方走，接口与业务逻辑跟着企业自己的系统走。